3 ms·

Some copy paste from previous posts Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as impleme

• nesarkvechnep 5y ago
  I've had great success with `Either` in Typescript. For each layer in the application I created ADTs representing the possible errors and used them in `Either`s. Each layer maps the lower layer errors to it's own.
• nlitened 5y ago
  From what I’ve seen so far, in reality people tend to overuse the `try!` macros, which leads to the same old bubbling exceptions semantic, but more verbose, less performant, and lacking stack traces.
  • jcelerier 5y ago
    Right, with exceptions you can `catch throw` to always get a stack trace of when the exception is thrown
• zvrba 5y ago
  Except that error returns such as Either have their own problems. What is the main complaint about checked exceptions in Java? Yes, handle or _declare_ them in method signatures: adding a checked exception to a previously non-throwing method breaks all callers. What happens when a previously non-erroring function must be changed to be able to report some error? Yes, the same: change the signature to return Either and fix all callers. And then what about conditions like division by zero, or arithmetic overflow? Are arithmetic _operators_ supposed to return Either/Option instead? Or just crash the program? Which may be a long-running server and only one request of many got corrupt? While not very ergonomic, I still prefer exceptions way more than return values. Ergonomics could be fixed by tooling; hopefully that will improve if developers start to demand it. Finally, even functional languages such as SML and Ocaml have exceptions where they are also even recommended for control flow such as breaking out of deep recursion.
  • rualca 5y ago
    > And then what about (...) If seems you've missed the whole point of suggesting the use of Either/Result monads. It's entirely irrelevant if you have legacy code that does not support returning error codes a certain way. The whole point of Either/Result monads , specially regarding exceptions, is that they provide a clean way to handle errors (and not exceptions) in the normal code path by explicitly making them a part of a function's codomain, and without relying on magic bubbling up. And no, Either/Result monads are only designed to handle expected results, not exceptional behavior. Perhaps your main source of confusion is conflating exceptions with an error condition. In that case, think of Either/Result monads as "I made a HTTP request and the response was a 200 or a 500 status, thus the code path follows accordingly" and exceptions as "I made a HTTP request and I got an OutOfMemoryException".
  • aidos 5y ago
    I just looked into this following someone else recommending Either and my knee jerk reaction is the same as yours. The nice thing about exceptions is that you get to take a large block of code and treat it as a whole fail-able unit. In terms of a control flow structure, being able to raise deep and goto nearer the top of the stack removes large amounts of boilerplate code, which, in my experience, makes the code more readable. I use exceptions sparingly and deliberately. And when used like that, I find them to be a helpful feature that improves the codebase.
• Buttons840 5y ago
  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.
      • 5y ago