This is a problem of architecture. Should you mix error handling with application logic? You have to handle errors somewhere, but they pollute the otherwise clean problem-solving code. One solution is to just let the exceptions bubble up and the other is to handle them immediately. If you let them bubble up, you can have a separate module that can do the right thing, notify the user, restart the app or something else. This way, the error handling is somewhat cleanly separated into its own thing. Sometimes you want to handle errors immediately, because only the code where the exception happens, knows how to deal with it. This is where return codes might be better. A lot of it depends on the desired behaviour. Sometimes you want the software to immediately exit or restart if there is a critical exception, sometimes you can safely ignore errors if real-time experience is more important. Sometimes all you want is to log the exception and/or notify the user. Does anyone have experience with aspect-oriented programming and does it help solve any of these problems?
Exceptions (2003)
21–30 of 93 posts
Re: Exceptions (2003)
#22Earlier quoted context omitted.
His argument is really against using exceptions as part of normal operation, which I agree with. I've noticed when writing plugins to big monolithic programs like 3DS Max and game engines that these tend to throw and catch exceptions as a matter of course, which is a pain when you're trying to debug your own plugin code. An exception should mean "normal operation cannot continue", and should signify a bug in your cod…
I got a question. Do you think it's okay use exceptions to end what would be otherwise an infinite loop? Python example: data = "" socket.settimeout(1.5) while 1: try: data += socket.recv(1024) except Exception,e: store_data(data) break If this is not okay, what would you change? (And yes, I know there are edge'ish cases were I'd miss some data here)
This is NOT OK. You're swallowing all exceptions and assuming that they are your special case.
The fix is to have a specific nonambiguous name for your exception, so that other error conditions still work properly. As examples consider the StopIteration and GeneratorExit exceptions from Python's standard library. (See http://docs.python.org/2/library/exceptions.html for a list of built-in exceptions.)
Re: Exceptions (2003)
#23While I'm not familiar with the Erlang paradigm that inspires it, the dire[1] library in Clojure is designed to decomplect error handling from code that may generate an error. I like this approach a lot.
Re: Exceptions (2003)
#24You can make methods easily return multiple values in C# with Tuples. They are very handy.
Re: Exceptions (2003)
#25Earlier quoted context omitted.
Isn't that what exceptions are used for in any language?
Certainly not. In Python, for example, exceptions are used to handle exceptional conditions . Here's an example. Say I'm writing a function and I have a dictionary I need to access values from often. Now say that 85% of the time the key I need is in the dictionary, but 15% of the time it is not. I could do this: if key in my_dict: execute_operation(my_dict[key]) else: pass So that if the key is not in the dictionary…
Unfortunately, the second one eats an uncaught KeyError raised deep inside execute_operation, not just my_dict[key] failing. Which may be easy to overcome if you wrote all the code and libraries that execute_operation calls, but nearly impossible otherwise.
Re: Exceptions (2003)
#26I am not a huge fan of exceptions per se, but it’s important to understand that they are a heuristic for minimizing ‘worry’ about things that are unlikely. I am not saying it’s a good thing, I am saying it’s the way people naturally work.
Let’s say there is a function that’s 20 lines long, and if you did a thorough analysis of possible error conditions, regardless of likelihood, you might come up with 50 or more.
We are not going to write code to address all 50 possibilities from the start. Instead, we are going de facto to wait and see what fails in the real world, and address them as we discover them, because we value our time. We make an economic distinction between a 1-in-1,000 problem, and a 1-in-1,000,000,000 problem.
Is this un-robust? Yes. Are we allowing exceptions to be a control-flow catch-all? Yes. Would a Go-like approach of simply returning error conditions reduce bugs? Probably. But it’s important to recognize programmers’ ‘revealed preference’ for exceptions.
Re: Exceptions (2003)
#27Some Haskellers treat exceptions as something that you only use if the program has entered an unrecoverable condition and needs to crash.
In C++, use exceptions when things go so badly that you have to metaphorically pack things up and send some people home. Because that's what exceptions are good at.
For example, I used to work on a system where there were various threads each controlling a different piece of hardware. But the hardware was hot-swapable, so it was possible that suddenly a thread would find itself trying to talk to hardware that was no longer there. We would throw an exception at the low level hardware access point, at catch at the (nearly) highest level of the thread. This allowed us to reclaim memory and other resources used by the thread in an orderly fashion, and return to a "ready for hardware insert" mode. This was key since the other threads were doing just fine and the overall program needed to continue.
Re: Exceptions (2003)
#28"Monday, October 13, 2003" - more like "the old new GOTO"; but apart from the out-of-the-blue rant about PHP (version 4, I guess?) at the bottom, this still seems applicable.
His argument is really against using exceptions as part of normal operation, which I agree with. I've noticed when writing plugins to big monolithic programs like 3DS Max and game engines that these tend to throw and catch exceptions as a matter of course, which is a pain when you're trying to debug your own plugin code. An exception should mean "normal operation cannot continue", and should signify a bug in your cod…
Exceptions aren't a debugging tool. You should use asserts for debugging. These asserts are then disabled via compile switches for the production version. Or you can write unit tests.
Re: Exceptions (2003)
#29The discussion around that time was interesting (though distributed around the blogosphere); Ned Batchelder had recently argued the opposite (and updated the argument specifically to take Joel's article into account)[0][1]. It was at about that same time that Damien Katz was becoming firmly convinced that Erlang and crash-only behaviour would be the way to go in designing CouchDB[2][3]. (Both Damien and Ned were at Iris/Lotus working on Notes and Domino, and I was a Domino dev at the time.)
[0] http://nedbatchelder.com/blog/200310/joel_on_exceptions.html [1] http://nedbatchelder.com/text/exceptions-vs-status.html [2] http://damienkatz.net/2004/08/crash-only-software.html [3] http://damienkatz.net/2004/09/crash-only-software-revisited....
Re: Exceptions (2003)
#30Earlier quoted context omitted.
Isn't that what exceptions are used for in any language?
Certainly not. In Python, for example, exceptions are used to handle exceptional conditions . Here's an example. Say I'm writing a function and I have a dictionary I need to access values from often. Now say that 85% of the time the key I need is in the dictionary, but 15% of the time it is not. I could do this: if key in my_dict: execute_operation(my_dict[key]) else: pass So that if the key is not in the dictionary…
As a C programer i consider the first method to be clearer and am still unconvinced that exceptions should be user for anything other than unrecoverable errors; exceptions have the stack unwinding feature.