hunchentoot

emote_addr; I will push this configuration to the GitHub repository too sometime this weekend.

empirical level, it's trivial to find dozens of instances of code on the internet where it's crystal clear that the direct caller of an erroring function is not responsible for error-handling. Here's one: on line 1471 of emacsclient.c[1], a call to connect() may fail - yet the caller, set_local_socket(), is clearly not responsible for e.g. quitting the application, because only its caller, set_socket()[2], has the contextual information necessary to know that quitting should not happen unless the attempts to open local UNIX domain and network sockets to the Emacs server also fail. That's it - counter-evidence to your claim. It's straight-up false. But, let's go and find a few more examples. Here[3] is a random screenshot of a Python error trace that I found on the internet. You see that bottom frame, listen()? It's calling the erroring function sock.bind(addr). Yet, it's pretty clear that listen() isn't the right place to handle the error - it's in the user's application, "ryu", because again, only that code has the contextual information necessary to determine the correct way to handle the error. Here[4] is another Python error trace - again, it's pretty clear that the place to handle the erroring getattr() call is not in its direct caller bind() in socket.py, but in the user application in siriServer.py. Finally, here's some Lisp code. The Hunchentoot web server has a ENSURE-PARSE-INTEGER function[5], which can fail if it receives a non-integer to parse. But, it simply doesn't have the contextual information necessary to handle the error, because it's called by URL-DECODE[6], which is called by FORM-URL-ENCODED-LIST-TO-ALIST[7], which is called by MAYBE-READ-POST-PARAMETERS[8], and that is where the error handling can, should, and must occur. It's crystal clear - errors are not required to be (or always capable of being) handled at the call site of the erroring function, and the reason for this is simply because context gets lost as you travel down the call stack, so that the point at which an error occurs often simply doesn't have the necessary context to recover from it correctly. > Falliable operations must be managed by the thing which calls them. Also false. Look at every one of the code examples I've linked. Go and look at code in general, actually. > Anything else is shadow control flow, which subverts understanding and negatively impacts reliability. It sounds like you don't understand exceptions very well. Go and read some code with exceptions - you'll see that the idea is extremely straightforward. Exceptions are very simple - they bubble up through the stack until handled, and that's it. They're far easier to understand than first-class functions, coroutines, monads, or any of another dozen different software engineering concepts that are also being put to extremely good use. [1] https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734... [2] https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734... [3] https://i.ytimg.com/vi/CryQPaz8UO0/maxresdefault.jpg [4] https://serverfault.com/questions/476715/python-socket-error... [5] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [6] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [7] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [8] https://github.com/edicl/hunchentoot/blob/18d76801150330a579...