4 ms·

> Errors-as-return values are less readable than conditions, not more - there's literally more visual noise on the screen. No. When you make a function call,

> Errors-as-return values are less readable than conditions, not more - there's literally more visual noise on the screen. No. When you make a function call, and that call can fail, then the happy-path and the sad-path are both things that you need to manage as a caller. Happy-path and sad-path are two equivalent states that both need to be accommodated by the program logic. Error handling code is not "noise". It is equally important to success-path code.

lanstin 4y ago
Maybe this is the fundamental argument here. Plenty of cases I have written code where I am trying to do something over a big set of things, e.g. check a file for hard-coded paths, or send a message to a lot of people; it isn’t weird for those things to fail. Maybe I couldn’t open the file. Maybe the file lacked hard coded paths. Maybe the sender lacked rights to send to that receiver, or maybe the receiver is currently offline. But if most of your code is some complex calculation, say weather simulation?, maybe there is by default just one path.
throw10920 4y ago
> No. Yes. There is literally more visual noise on the screen. This is not up for debate - more pixels are lit on the monitor you are looking at. > When you make a function call, and that call can fail, then the happy-path and the sad-path are both things that you need to manage as a caller. False - the direct caller is not responsible for error-handling, in general - some transitive super-caller will be. Errors as return values needlessly generate this visual noise for every caller, when not needed, in addition to introducing aforementioned coupling. > Error handling code is not "noise". It is equally important to success-path code. You're misunderstanding my point. 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.
- preseinger 4y ago
  Error handling is not visual noise. It is equally important to non-error-handling code paths. The direct caller is _absolutely_ responsible for error handling. > What is noise is forcing every single function call between the appropriate error-handling point and the error location to have extra useless junk. No. Falliable operations must be managed by the thing which calls them. Anything else is shadow control flow, which subverts understanding and negatively impacts reliability.
  - throw10920 4y ago
    > 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/3af9e84ff59811734dcbb5d55e04e1fdb7051e77/lib-src/emacsclient.c#L1471 https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734... [2] https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734dcbb5d55e04e1fdb7051e77/lib-src/emacsclient.c#L1542 https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734... [3] https://i.ytimg.com/vi/CryQPaz8UO0/maxresdefault.jpg https://i.ytimg.com/vi/CryQPaz8UO0/maxresdefault.jpg [4] https://serverfault.com/questions/476715/python-socket-error-errno-98-address-already-in-use https://serverfault.com/questions/476715/python-socket-error... [5] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f02f9a8bdab2b4a7037c652/util.lisp#L189 https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [6] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f02f9a8bdab2b4a7037c652/util.lisp#L196 https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [7] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f02f9a8bdab2b4a7037c652/util.lisp#L248 https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [8] https://github.com/edicl/hunchentoot/blob/18d76801150330a579a48d593eb6c2df13e83cd1/request.lisp#L287 https://github.com/edicl/hunchentoot/blob/18d76801150330a579...

lanstin 4y ago

Maybe this is the fundamental argument here. Plenty of cases I have written code where I am trying to do something over a big set of things, e.g. check a file for hard-coded paths, or send a message to a lot of people; it isn’t weird for those things to fail. Maybe I couldn’t open the file. Maybe the file lacked hard coded paths. Maybe the sender lacked rights to send to that receiver, or maybe the receiver is currently offline. But if most of your code is some complex calculation, say weather simulation?, maybe there is by default just one path.

throw10920 4y ago

> No. Yes. There is literally more visual noise on the screen. This is not up for debate - more pixels are lit on the monitor you are looking at. > When you make a function call, and that call can fail, then the happy-path and the sad-path are both things that you need to manage as a caller. False - the direct caller is not responsible for error-handling, in general - some transitive super-caller will be. Errors as return values needlessly generate this visual noise for every caller, when not needed, in addition to introducing aforementioned coupling. > Error handling code is not "noise". It is equally important to success-path code. You're misunderstanding my point. 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.

preseinger 4y ago
Error handling is not visual noise. It is equally important to non-error-handling code paths. The direct caller is _absolutely_ responsible for error handling. > What is noise is forcing every single function call between the appropriate error-handling point and the error location to have extra useless junk. No. Falliable operations must be managed by the thing which calls them. Anything else is shadow control flow, which subverts understanding and negatively impacts reliability.
- throw10920 4y ago
  > 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/3af9e84ff59811734dcbb5d55e04e1fdb7051e77/lib-src/emacsclient.c#L1471 https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734... [2] https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734dcbb5d55e04e1fdb7051e77/lib-src/emacsclient.c#L1542 https://github.com/emacs-mirror/emacs/blob/3af9e84ff59811734... [3] https://i.ytimg.com/vi/CryQPaz8UO0/maxresdefault.jpg https://i.ytimg.com/vi/CryQPaz8UO0/maxresdefault.jpg [4] https://serverfault.com/questions/476715/python-socket-error-errno-98-address-already-in-use https://serverfault.com/questions/476715/python-socket-error... [5] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f02f9a8bdab2b4a7037c652/util.lisp#L189 https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [6] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f02f9a8bdab2b4a7037c652/util.lisp#L196 https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [7] https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f02f9a8bdab2b4a7037c652/util.lisp#L248 https://github.com/edicl/hunchentoot/blob/0023dd3927e5840f1f... [8] https://github.com/edicl/hunchentoot/blob/18d76801150330a579a48d593eb6c2df13e83cd1/request.lisp#L287 https://github.com/edicl/hunchentoot/blob/18d76801150330a579...