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

[SealabJaster]

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:

```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.