25 ms·

Exceptions are clearly inferior to an alternative strategy of handling errors as values rather than something exceptional to catch. Exceptions to me started off

by jimmy1 8y ago

Exceptions are clearly inferior to an alternative strategy of handling errors as values rather than something exceptional to catch. Exceptions to me started off as a humble concept (if something truly exceptional happens, do x y or z, but in 99% of cases you will probably just want to abort or crash) Instead exceptions have become every day errors. Like the article defines, > The handling of exceptional cases; perhaps a service failed for an unexpected reason like a network failure Really? A service failure or network failure is an exceptional case for you? This should be planned for, and built into the architecture! Plan for the network always failing! Recover gracefully! That is what retry strategies like exponential backoff are for, and circuit breakers, idempotent requests so you can simply cancel and try again, so on and so forth. Instead of treating everything as exceptional, when you treat errors as values, they lend you down the path of actually handling them. As a side effect of this, you build more robust systems. Bubbling up an error to the top when errors are values are seen as an anti-pattern, only to be done in the most rare of circumstances. Again, from the article, > All other exceptions - Signifies my server has a bug Then your server should crash! Take it out of the load balancer, stop the damage! If you truly can't classify it, it's truly unknown or exceptional, abort!

orf 8y ago
Don't confuse the name "exceptions" with the English definition. They are just a mechanism for returning values, usually signifying errors (but not always: see Python StopIteration), without using a standard 'return'. So no, nobody is considering a network failure an exceptional case.
ec109685 8y ago
> Then your server should crash! Take it out of the load balancer, stop the damage! If you truly can't classify it, it's truly unknown or exceptional, abort! What if all the servers have the same bug? Should they all crash or should they alert and allow an operator to chose how to handle? If it is a rarely hit error case, staying up is better than creating a complete outage.
wvenable 8y ago
> Really? A service failure or network failure is an exceptional case for you? This should be planned for, and built into the architecture! Plan for the network always failing! Recover gracefully! Exception do let you plan for exactly that while ignoring the ridiculous notion that you can know every possible error that every function can trigger now or in the future. Instead you plan for exactly where you can restart a network operation in the code and put your exception handler in that spot. You don't need to do anything else. It's simple and effective. The alternative is to write a lot of boilerplate code that does nothing but get you to that same point.
- jimmy1 8y ago
  > while ignoring the ridiculous notion that you can know every possible error that every function can trigger now or in the future. If you have a statically typed language, and defined error types that are only thrown in certain situations, can you please explain to me why it is so ridiculous to think you cannot know every possible error that will occur? If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? Additionally, say there are some additional outside runtime errors that can occur such as out of memory errors, again these are ideally known ahead of time, and you can use a constrained runtime to minimize them. Taking this a little further, if you cannot know every possible error, then you cannot possibly have any sort of remote closeness to formal verification, and that means our software systems that rely on more stringent verification methods are a lie. (I hope you don't write any medical device software!) I am making an assumption and maybe think you are just trying to say this heuristically ? Like maybe we are all writing web software, and meh, close enough if you handle most errors, and "meh" for the rest of them? I mean I certainly think that works for the majority of development that happens, but more and more we are becoming keenly aware that our software has real world impact on people's lives and maybe some added stringency is what we need.
  - wvenable 8y ago
    You know every single error every framework function can call? Every single error in your entire code base? What about tomorrow when Bob changes some code? > If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? How often do you have a single function in your call stack? Do you also handle/swallow every error in every function or do you propagate those errors? So function q throws errors it was called by function p that throws and by the time you get back to a the list is a lot longer than x, y, z. Formal verification is a red herring. I know my software either handles all the errors that it can or stops processing and informs someone. Error types don't remove complexity or make humans better at error handling.

by jimmy1 8y ago

orf 8y ago

Don't confuse the name "exceptions" with the English definition. They are just a mechanism for returning values, usually signifying errors (but not always: see Python StopIteration), without using a standard 'return'. So no, nobody is considering a network failure an exceptional case.

ec109685 8y ago

> Then your server should crash! Take it out of the load balancer, stop the damage! If you truly can't classify it, it's truly unknown or exceptional, abort! What if all the servers have the same bug? Should they all crash or should they alert and allow an operator to chose how to handle? If it is a rarely hit error case, staying up is better than creating a complete outage.

wvenable 8y ago

> Really? A service failure or network failure is an exceptional case for you? This should be planned for, and built into the architecture! Plan for the network always failing! Recover gracefully! Exception do let you plan for exactly that while ignoring the ridiculous notion that you can know every possible error that every function can trigger now or in the future. Instead you plan for exactly where you can restart a network operation in the code and put your exception handler in that spot. You don't need to do anything else. It's simple and effective. The alternative is to write a lot of boilerplate code that does nothing but get you to that same point.

jimmy1 8y ago
> while ignoring the ridiculous notion that you can know every possible error that every function can trigger now or in the future. If you have a statically typed language, and defined error types that are only thrown in certain situations, can you please explain to me why it is so ridiculous to think you cannot know every possible error that will occur? If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? Additionally, say there are some additional outside runtime errors that can occur such as out of memory errors, again these are ideally known ahead of time, and you can use a constrained runtime to minimize them. Taking this a little further, if you cannot know every possible error, then you cannot possibly have any sort of remote closeness to formal verification, and that means our software systems that rely on more stringent verification methods are a lie. (I hope you don't write any medical device software!) I am making an assumption and maybe think you are just trying to say this heuristically ? Like maybe we are all writing web software, and meh, close enough if you handle most errors, and "meh" for the rest of them? I mean I certainly think that works for the majority of development that happens, but more and more we are becoming keenly aware that our software has real world impact on people's lives and maybe some added stringency is what we need.
- wvenable 8y ago
  You know every single error every framework function can call? Every single error in your entire code base? What about tomorrow when Bob changes some code? > If function a calls function b, and function b throws errors x y and z, why is it I cannot check for x y and z in function a? How often do you have a single function in your call stack? Do you also handle/swallow every error in every function or do you propagate those errors? So function q throws errors it was called by function p that throws and by the time you get back to a the list is a lot longer than x, y, z. Formal verification is a red herring. I know my software either handles all the errors that it can or stops processing and informs someone. Error types don't remove complexity or make humans better at error handling.