On 6/4/22 10:17, Ola Fosheim Grøstad wrote:
> Why can't Error unwind the stack properly?
Errors are thrown when the program is discovered to be in an invalid
state. We don't know what happened and when. For example, we don't know
whether the memory has been overwritten by some rogue code. Or perhaps a
bit got flipped in memory.
When the state of the program is discovered to be outside of what we
think is normal, we cannot execute further code. It would be madness to
wish that some cleanup code would do the right thing when e.g. we were
sure that an array would never be empty but we found it to be empty.
What happened? What can we assume. We don't know and we cannot assume
any state.
(As has been stated many times in this thread and elsewhere, Exceptions
are different. They don't have anything to do with invariants.)
> 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.
Is the service in a usable state?
> If you allow the whole service to go down then you have opened a
> Denial-of-Service vector
Possibly. Not shutting down might produce incorrect results. Do we
prefer up but incorrect or dead?
> 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!
I hope there is a way of aborting the program when there are invariant
violations discovered.
Ali
