Errors in Go: From denial to acceptance
<i>> Nothing explodes, the code keeps running</i><p>in my book, this is not a good thing but a very bad thing.<p>If I'm a library function somewhere all the way down the stack and I'm at a point where something about the state I'm working on isn't up to the specification I expect them to be, then I'd prefer the safety of blowing up.<p>I don't want to be responsible for my callers eventually ignoring my error code and happily churning along thinking that I have fulfilled my promise and enacted the side-effect I promised to have.<p>If something else, far removed from me depends on me to having had the side effect, <i>it</i> might blow up. Or it might write corrupt data. Suddenly a thing that went wrong at one place blows up at a totally different place which makes it incredibly hard to debug.<p>And if the world is burning, "hard to debug" is about the least wanted property a problem could have.<p>Oh no. If the world is burning for me, then I absolutely do not want to continue.<p>But I also do not want to abort the daemon process I'm being hosted in because that would mean affecting other threads of execution (be it threads, coroutines or whatever else) where the world might be in a totally acceptable state.<p>Calling `exit` in a library function is outright rude.<p>If I get to `throw`, I can make absolutely sure that I made it clear to my caller or my caller's caller that I panicked while there's still a chance for my parent daemon to not die but handle my panic cleanly. Or, my caller, or its caller was prepared for me failing and can chose another way out.<p>But by throwing I can raise a very strong signal that something is wrong and I have the guarantee that if I'm being ignored, then I <i>will</i> kill my parent which is totally their fault for ignoring me and it will be <i>very</i> obvious what happened, why it happened, and, above all, <i>where</i> it happened.<p>If I'm an engineer wearing my devops hat, I'd <i>much</i> rather debug an uncaught exception causing a stack trace to be logged in sentry.io (or whatever else you use. I'm a very happy sentry customer, but your might have your own tool) rather than corrupted data that might have been corrupted months ago.