> Error handling is not visual noise.

You clearly did not actually read my previous comment before replying to it. Let me quote it:

"I never said that error-handling code is noise - it isn't. What is noise is forcing every single function call between the appropriate error-handling point and the error location to have extra useless junk. When there's an error, you should see exactly two things in your codebase: some stuff at the point where the error is thrown, and some stuff at the point where the error is handled - and, given that the place where the error should be handled is rarely the direct caller, you should see nothing in between."

Please read this carefully and respond to it.

> The direct caller is _absolutely_ responsible for error handling.

This is objectively false, both on an empirical level, and on a theoretical one.

On the 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...