4 ms·

Very well articulated. That link you posted is great as well. The issue I've always had with exception systems is the loss of control over the control flow, but

Very well articulated. That link you posted is great as well. The issue I've always had with exception systems is the loss of control over the control flow, but the problem with errors is that it's not that clear what situations are errors. Libraries that are designed with exception systems are in the business of second-guessing what's an error for the caller. For that reason, in practice, exceptions tend to (either not be handled or) be transformed/interpreted at (almost) every place before being forwarded up the call stack. In the end exceptions are only an additional mechanism that the programmer painfully has to deal with. It would have been better to use normal values describing the situation (error or not) without any exception semantics attached. A perspective on the commonly seen argument that all those "if err != nil" are cumbersome is that you shouldn't have many of those, and most of them should be a "return" and nothing more. Complex error state (or any state for that matter) belongs not on the call stack (nor in return values) but it should be stored in data structures so it can be handled appropriately and at the appropriate time.

Joker_vD 5y ago
> Libraries that are designed with exception systems are in the business of second-guessing what's an error for the caller Okay, let's take some concrete example: a library that does a network call in order to accomplish it task. Imagine it sends/receives all relevant data, and then the TCP connection is closed from the remote end with RST instead of FIN: for the library it looks like a RemoteHostClosedError being thrown. What next? Some libraries would second-guess the caller that it's not an error, swallow this exception and return the data as normal — that's bad, we don't like those libraries. Some libraries second-guess the caller that it is an error and rethrow it, throwing away the would-be returned data — that's bad, we don't like those libraries. A good library would instead not second-guess the caller and do... what, exactly? Return both the resulting data and the exception? But that's the case when the error happened on the wind-down, what if it happened in the middle: should the library return some sort of "resumable context" together with an error? Or what?
- jstimpfle 5y ago
  So, the library received some data. It also received an RST. It should store both pieces of information in the connection handle (library data structure). The caller can then inspect the state and decide what to do. There are other options. The library could for example throw an exception and never report the received data. It's a different paradigm - making choices to present a convenient API that works in the common cases, at the cost of taking away control over the less common ones. APIs like this are popular and maybe useful for scripting languages, but probably less useful in larger systems.
aidenn0 5y ago
Allow me to include my mandatory comment about how other languages need to (re)discover Common Lisp's condition and restart system. The condition system from Lisp gives handlers the option of running before the stack is rewound; other languages put various amounts of state in their exception objects, which only gives you a portion of the power of just not destroying that state in the first place. Restarts let callers communicate down the stack what to do when certain conditions happen, which removes the need for second-guessing and allows for better locality of code; having the "When X, Y" closer to the code that is responsible for the decision rather than the code that just happens to be closer to X is almost always a win.
- jstimpfle 5y ago
  Running various callbacks or whatever is still overthinking the problem, similar to throwing exceptions. There's still a preconceived notion that anybody would want to (or could) handle a certain state right then and there. In general, some responsible code does something about the state that is created by the library. But also, in general it isn't the code that issued the request, nor should happen right when the library detects the error. In theory, such callbacks are at least as powerful as only storing the state so the client can inspect it later - because a trivial callback is free to only store the state so the client can inspect it later. However, in practice, callbacks lead to overly complex code (beyond some trivial lambdas), and having to provide a callback encourages bad program structure - creating a temporal coupling between the occurence of some event and the handling of it
  - jstimpfle 5y ago
    There are valid usecases for libraries to take callbacks to parameterize stuff - namely, when the library needs something from the client that the client should always be able to provide synchronously, and it would be too much work to create an interface to let the client pass in the information asynchronously. Example: memory allocation? But it doesn't work the other way around: The library shouldn't try to restrict the user about all the things it should want to do. Taking dozens of hooks to cover all possible situations will only make the API harder and harder to use.

Joker_vD 5y ago

> Libraries that are designed with exception systems are in the business of second-guessing what's an error for the caller Okay, let's take some concrete example: a library that does a network call in order to accomplish it task. Imagine it sends/receives all relevant data, and then the TCP connection is closed from the remote end with RST instead of FIN: for the library it looks like a RemoteHostClosedError being thrown. What next? Some libraries would second-guess the caller that it's not an error, swallow this exception and return the data as normal — that's bad, we don't like those libraries. Some libraries second-guess the caller that it is an error and rethrow it, throwing away the would-be returned data — that's bad, we don't like those libraries. A good library would instead not second-guess the caller and do... what, exactly? Return both the resulting data and the exception? But that's the case when the error happened on the wind-down, what if it happened in the middle: should the library return some sort of "resumable context" together with an error? Or what?

jstimpfle 5y ago
So, the library received some data. It also received an RST. It should store both pieces of information in the connection handle (library data structure). The caller can then inspect the state and decide what to do. There are other options. The library could for example throw an exception and never report the received data. It's a different paradigm - making choices to present a convenient API that works in the common cases, at the cost of taking away control over the less common ones. APIs like this are popular and maybe useful for scripting languages, but probably less useful in larger systems.

aidenn0 5y ago

Allow me to include my mandatory comment about how other languages need to (re)discover Common Lisp's condition and restart system. The condition system from Lisp gives handlers the option of running before the stack is rewound; other languages put various amounts of state in their exception objects, which only gives you a portion of the power of just not destroying that state in the first place. Restarts let callers communicate down the stack what to do when certain conditions happen, which removes the need for second-guessing and allows for better locality of code; having the "When X, Y" closer to the code that is responsible for the decision rather than the code that just happens to be closer to X is almost always a win.

jstimpfle 5y ago
Running various callbacks or whatever is still overthinking the problem, similar to throwing exceptions. There's still a preconceived notion that anybody would want to (or could) handle a certain state right then and there. In general, some responsible code does something about the state that is created by the library. But also, in general it isn't the code that issued the request, nor should happen right when the library detects the error. In theory, such callbacks are at least as powerful as only storing the state so the client can inspect it later - because a trivial callback is free to only store the state so the client can inspect it later. However, in practice, callbacks lead to overly complex code (beyond some trivial lambdas), and having to provide a callback encourages bad program structure - creating a temporal coupling between the occurence of some event and the handling of it
- jstimpfle 5y ago
  There are valid usecases for libraries to take callbacks to parameterize stuff - namely, when the library needs something from the client that the client should always be able to provide synchronously, and it would be too much work to create an interface to let the client pass in the information asynchronously. Example: memory allocation? But it doesn't work the other way around: The library shouldn't try to restrict the user about all the things it should want to do. Taking dozens of hooks to cover all possible situations will only make the API harder and harder to use.