[OT] - C++ exceptions are becoming more and more problematic

[Alexandru Ermicioi]

On Thursday, 24 February 2022 at 03:42:42 UTC, SealabJaster wrote:
> 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.

It may be simpler, but it is also way noisier than try catch & 
throw, and way more easier to trip over it and have a bug.

>
> 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:
>
> ```d
> // 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!
>
> ```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.
>
> ```d
> 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 at 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.

Just why do we need new syntax? Can't we have it in terms of 
existing one?

Also proposed value exceptions look terribly similar to java 
checked exceptions, which are avoided in java world due to 
spamming issue it causes when trying to propagate them across 
call chain up to location where it is caught. Having them in D is 
like importing a bad feature from java, at least in current 
version they are suggested.