4 ms·

To answer the titular question: Because (1) most software, and most frameworks, are designed optimistically, thinking almost exclusively about when everything g

by alanh 15y ago

To answer the titular question: Because (1) most software, and most frameworks, are designed optimistically, thinking almost exclusively about when everything goes well. And (2) because of positive bias we test cases we expect to go well.† For example, in the Tornado web stack, it’s certainly possible to gracefully handle an exception you threw in the middle of responding to a method, but you have to basically augment the framework to do so. It’s practically unfinished in that sense. Would that have been the case if it were designed with failure modes occupying its creators’ minds even half as much as successful ones? †The most fun example/intro to this I’ve seen: http://www.fanfiction.net/s/5782108/8/Harry_Potter_and_the_Methods_of_Rationality http://www.fanfiction.net/s/5782108/8/Harry_Potter_and_the_M...

ankrgyl 15y ago
Your analysis of Tornado is unfair. It offers easy ways to throw specific HTTPErrors, and those are handled exactly as they should be. If you throw an exception that Tornado doesn't know about, then it simply by default notifies the user that an internal server error occurred. It is extremely easy to design your code to throw the right http exceptions, and it is just as easy to write your own custom python exceptions that cooperate with their stack. You most certainly don't have to modify the framework itself, and tornado is designed specifically to be easy to extend.
- alanh 15y ago
  You're right, but doing things like falling back to another handler or doing anything meaningful is hard. That is, top-notch experiences in the face of failure aren't obviously easy.
zmmmmm 15y ago
> Because (1) most software, and most frameworks, are designed optimistically, thinking almost exclusively about when everything goes well. And (2) because of positive bias we test cases we expect to go well Yes, this realization finally hit me a few years ago and started to make me reign in my use of exceptions. I realized that exceptions are all about giving priority to the optimistic case in the code - making it as clear and simple and with as little branching as possible. However after seeing projects through a full lifecycle (from initial conception through to maintenance in production) I now realize that the really important code - the code that we spend most of our time trying to figure out in maintenance over the lifetime of the application and whose state is most hard to understand and deal with - is in fact the error handling code and that exceptions focus on hiding that code and making it "disappear" and seem implicit. What seems like a win initially can be a huge loss when you're trying to write a robust system where every possible behavior is explicit and well understood.
- moe 15y ago
  Don't equate exception with "Error". Many common problems, especially in network servers, can be solved quite elegantly with an "exception driven design". In those scenarios the exceptions serve as a vehicle to bubble state through multiple layers. Pretty much like an event-framework, except many people don't realize they have that baked right into their language. A simple example would be a network-server that detects a protocol phase change at the lowest protocol level. By raising a "PhaseChange"-Exception you can quite nicely propagate such an event to the higher layers that need to know about it, without resorting to duplicated/shared state or awkward call-chains that introduce nasty dependencies and then need their own exception handling, and without running into potential synchronization issues.

by alanh 15y ago

ankrgyl 15y ago

Your analysis of Tornado is unfair. It offers easy ways to throw specific HTTPErrors, and those are handled exactly as they should be. If you throw an exception that Tornado doesn't know about, then it simply by default notifies the user that an internal server error occurred. It is extremely easy to design your code to throw the right http exceptions, and it is just as easy to write your own custom python exceptions that cooperate with their stack. You most certainly don't have to modify the framework itself, and tornado is designed specifically to be easy to extend.

alanh 15y ago
You're right, but doing things like falling back to another handler or doing anything meaningful is hard. That is, top-notch experiences in the face of failure aren't obviously easy.

zmmmmm 15y ago

> Because (1) most software, and most frameworks, are designed optimistically, thinking almost exclusively about when everything goes well. And (2) because of positive bias we test cases we expect to go well Yes, this realization finally hit me a few years ago and started to make me reign in my use of exceptions. I realized that exceptions are all about giving priority to the optimistic case in the code - making it as clear and simple and with as little branching as possible. However after seeing projects through a full lifecycle (from initial conception through to maintenance in production) I now realize that the really important code - the code that we spend most of our time trying to figure out in maintenance over the lifetime of the application and whose state is most hard to understand and deal with - is in fact the error handling code and that exceptions focus on hiding that code and making it "disappear" and seem implicit. What seems like a win initially can be a huge loss when you're trying to write a robust system where every possible behavior is explicit and well understood.

moe 15y ago
Don't equate exception with "Error". Many common problems, especially in network servers, can be solved quite elegantly with an "exception driven design". In those scenarios the exceptions serve as a vehicle to bubble state through multiple layers. Pretty much like an event-framework, except many people don't realize they have that baked right into their language. A simple example would be a network-server that detects a protocol phase change at the lowest protocol level. By raising a "PhaseChange"-Exception you can quite nicely propagate such an event to the higher layers that need to know about it, without resorting to duplicated/shared state or awkward call-chains that introduce nasty dependencies and then need their own exception handling, and without running into potential synchronization issues.