Comparing Exceptions and Errors

[Ola Fosheim Grøstad]

On Saturday, 4 June 2022 at 16:55:50 UTC, Sebastiaan Koppe wrote:
> The reasoning is simple: Error + nothrow will sidestep any RAII 
> you may have. Since you cannot know what potentially wasn't 
> destructed, the only safe course of action is to abandon ship.

Why can't Error unwind the stack properly?

> Yes, in plenty of cases that is completely overkill.
>
> Then again, programs should be written to not assert in the 
> first place.

In a not-miniscule service you can be pretty certain that some ±1 
bugs will be there, especially in a service that is receiving new 
features on a regular basis. So, if you get an index/key 
error/null-dereferencing that wasn't checked for, unwinding that 
actor/task/handler makes sense, shutting down the service doesn't 
make sense.

If you allow the whole service to go down then you have opened a 
Denial-of-Service vector, which is a problem if the service is 
attracting attention from teens/immature adults. (E.g. games, 
social apps, political sites, educational sites etc).

> Considering most asserts I have seen are either due to a bad 
> api or just laziness - and shouldn't have to exist in the first 
> place - maybe it's not that bad.

Well, problem is if a usually reliable subsystem is 
intermittently flaky, and you get this behaviour, then that isn't 
something you can assume will be caught in tests (you cannot test 
for all scenarios, only the likely ones).

I am not a fan of Go, but it is difficult to find a more balanced 
solution, and Go 1.18 has generics, so it is becoming more 
competitive!

At the end of the day you don't have to love a language to choose 
it… and for a service, runtime behaviour is more important than 
other issues.