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.
