Permalink
Reply
On Thursday, 24 February 2022 at 00:51:31 UTC, Alexandru Ermicioi wrote:
>Go is a no go, due to constant if else error checking it forces user to do.
Personally I actually kind of prefer how Go handles things. I know people absolutely love to shit on the if err != nil spam, but to me it makes control flow really simple to follow.
I think if we were to have value-type exceptions in D, the most important thing would be syntax.
Some very not thought out and wacky ideas to try and spark someone else to make an actually good idea:
// Running a series of functions, and only caring if they returned an exception afterwards
// (this particular syntax would obviously introduce ambiguous syntax if used, but it's an example)
alias ConvException = ValueException!"conv";
// In this example, functions can only return a single type of exception
int toInt(string str) throw(ConvException)
{
if(isNumber(str))
return toNumber(str);
throw typeof(throw)("str is not a number");
}
int a;
int b;
// Even if an exception is thrown, things are still ran until the end
// only then are the catch statements ran.
try(ConvException ex) {
a = toInt("123") catch(ex);
b = (toInt("345") catch(ex) + toInt("abc") catch(ex));
}
catch(ConvException ex)
{
writeln(ex.msg);
return -1;
}
On a similar vein, if we have that sort of catch expression shown above, we could possibly make our own version of if err != nil spam look even worse :D!
ConvException ex;
if(toInt("123") catch(ex) + toInt("abc") catch(ex) && ex.isError)
{
writeln(ex.msg);
return -1;
}
On the topic of function chaining, let me introduce you to this beauty that my head just came up with.
Exception1 a;
Exception2 b;
Exception3 c;
// "@a" means "capture any exception into `a` and go straight to the catch block if something was thrown.
try someValue.func1()@a.func2()@b.func3@c
catch(a){}
catch(b){}
catch(c){}
(Don't ever let me design my own language).
But the point is, if we want to avoid Go's if-else spam, we need some other weird syntax to sugar on top of things.
