17 ms·

Two sides of the same coin. If error values like Either take over people will probably create abstractions (macros, monads, IDE plugins, whatever) to automatica

Two sides of the same coin. If error values like Either take over people will probably create abstractions (macros, monads, IDE plugins, whatever) to automatically propagate error values up the stack, then we're back where we started. I'm dealing with some code now that loves to use error values like "not found". Error values can be poorly done too. I've never seen exceptions quite so poorly done, they always at least have a stacktrace as a start to figuring out what they mean. I don't know where to start when I get the string "not found" and nothing else. Guess I'll use a debugger? I'll probably find it was division by zero or something, then got turned into the string "not found". Exceptions carry stacktraces which are really useful, and hard to replace with a string or any user defined object. And "panics" will always exist, so the idea of errors going up the stack through an alternate channel will never go away, and there needs to be ways to recover from those panics. So really, the choice is we use exceptions (or "panics") AND error values, or just exceptions. Using only error values is not an option.

lanstin 5y ago
The reason so much low level code is written in C is that not having exceptions forces one to write robust code. Panics stop the kernel. Sigsegv kills the CPython process. Exceptions make it extremely difficult to have that level of robustness.
- lanstin 5y ago
  To be more explicit, C stays around despite the memory unsafeness because the code written without exceptions just works so well. In the 90s, I worked writing in C long lived servers that had the philosophy to never ever exit because of bytes read from the network and always trigger a core dump and exit on any internal application state inconsistency. In production the process would be restarted and the stack trace emailed to the author, with core available if needed. It was possible and pretty routine to have code that would run hundreds of days, years even once the feature was basically done, without restart. Exceptions make that degree of reliability really hard for us simple minded engineers to achieve.
  - Buttons840 5y ago
    Setting aside my personal opinions. I think it's safe to say that there are pros and cons to exceptions versus error values. But, I think it's even more safe to say that error values are not a silver bullet that inevitably lead to robust code. As mentioned I'm personally dealing with some very poorly done error values right now. I resent the idea that error values "force" robust code (I wish that force was in effect on my own project), or "just works so well." They're really not that different, the two approaches.

lanstin 5y ago

The reason so much low level code is written in C is that not having exceptions forces one to write robust code. Panics stop the kernel. Sigsegv kills the CPython process. Exceptions make it extremely difficult to have that level of robustness.

lanstin 5y ago
To be more explicit, C stays around despite the memory unsafeness because the code written without exceptions just works so well. In the 90s, I worked writing in C long lived servers that had the philosophy to never ever exit because of bytes read from the network and always trigger a core dump and exit on any internal application state inconsistency. In production the process would be restarted and the stack trace emailed to the author, with core available if needed. It was possible and pretty routine to have code that would run hundreds of days, years even once the feature was basically done, without restart. Exceptions make that degree of reliability really hard for us simple minded engineers to achieve.
- Buttons840 5y ago
  Setting aside my personal opinions. I think it's safe to say that there are pros and cons to exceptions versus error values. But, I think it's even more safe to say that error values are not a silver bullet that inevitably lead to robust code. As mentioned I'm personally dealing with some very poorly done error values right now. I resent the idea that error values "force" robust code (I wish that force was in effect on my own project), or "just works so well." They're really not that different, the two approaches.