Comments on: The best way to handle exceptions http://www.drmaciver.com/2010/04/the-best-way-to-handle-exceptions/ Mon, 06 Feb 2012 22:56:11 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: @ndy http://www.drmaciver.com/2010/04/the-best-way-to-handle-exceptions/#comment-1975 @ndy Tue, 21 Jun 2011 10:20:42 +0000 http://www.drmaciver.com/?p=3860#comment-1975 I think that this feeds into higher level design issues. Often you don't want the program to crash. Perhaps because you've built it as a big monolith and have lots of state that you need to save; or whatever. If you're using a multiprogramming approach with lots of tools that do one thing well then it matters less if that one program crashes as opposed to the entire stack. I think that this feeds into higher level design issues. Often you don’t want the program to crash. Perhaps because you’ve built it as a big monolith and have lots of state that you need to save; or whatever. If you’re using a multiprogramming approach with lots of tools that do one thing well then it matters less if that one program crashes as opposed to the entire stack.

]]> By: Dave Hall http://www.drmaciver.com/2010/04/the-best-way-to-handle-exceptions/#comment-1933 Dave Hall Wed, 15 Jun 2011 17:27:35 +0000 http://www.drmaciver.com/?p=3860#comment-1933 Something worth pointing out here is the new error handling mechanisms that were introduced in Python 3.1. This new feature made the Java-style exception wrapping / chaining built-in to the language. Thus, in Python 3, it's now okay to write: try: connect_to_server() except IOError as ex: raise CouldNotConnectToServerError("Could not connect to the server") This code snippet, rather than hiding the original error, actually adds a nicer user-friendly message to the stack trace. The resultant output, if allowed to propagate and crash the program, looks something like this: CouldNotConnectToServerError "Could not connect to the server" Line 4 in server.py This exception was caused by IOError "DNS did not resolve" Line 354 in dns.py Line 200 in net.py Line 456 in foo.py And so on. Yes, it's basically the same as the Java wrapping method, but it encourages a workflow whereby you don't have to worry about hiding debugging information by raising your own, more helpful exceptions. Rather than one giant stack trace, you have several bitesize ones. Obviously, you can still just print to stderr and exit, but at least now you have to try a bit harder to hide valuable information. Something worth pointing out here is the new error handling mechanisms that were introduced in Python 3.1. This new feature made the Java-style exception wrapping / chaining built-in to the language.

Thus, in Python 3, it’s now okay to write:

try:
connect_to_server()
except IOError as ex:
raise CouldNotConnectToServerError(“Could not connect to the server”)

This code snippet, rather than hiding the original error, actually adds a nicer user-friendly message to the stack trace. The resultant output, if allowed to propagate and crash the program, looks something like this:

CouldNotConnectToServerError “Could not connect to the server”
Line 4 in server.py

This exception was caused by IOError “DNS did not resolve”
Line 354 in dns.py
Line 200 in net.py
Line 456 in foo.py

And so on. Yes, it’s basically the same as the Java wrapping method, but it encourages a workflow whereby you don’t have to worry about hiding debugging information by raising your own, more helpful exceptions. Rather than one giant stack trace, you have several bitesize ones. Obviously, you can still just print to stderr and exit, but at least now you have to try a bit harder to hide valuable information.

]]> By: david http://www.drmaciver.com/2010/04/the-best-way-to-handle-exceptions/#comment-1149 david Tue, 27 Apr 2010 20:10:58 +0000 http://www.drmaciver.com/?p=3860#comment-1149 Please read the article before commenting. That is not what people are doing that I am objecting to. Please read the article before commenting. That is not what people are doing that I am objecting to.

]]> By: Matt http://www.drmaciver.com/2010/04/the-best-way-to-handle-exceptions/#comment-1148 Matt Tue, 27 Apr 2010 19:52:41 +0000 http://www.drmaciver.com/?p=3860#comment-1148 "So by including this rescue, we have lost information." In Java you can specify a cause in .Net an InnerException, so you don't lose any information but add to it. I'm sure other platforms have similar facilities. “So by including this rescue, we have lost information.”

In Java you can specify a cause in .Net an InnerException, so you don’t lose any information but add to it. I’m sure other platforms have similar facilities.

]]> By: david http://www.drmaciver.com/2010/04/the-best-way-to-handle-exceptions/#comment-1147 david Tue, 27 Apr 2010 14:15:20 +0000 http://www.drmaciver.com/?p=3860#comment-1147 Note that I specifically listed that as a case where actually a friendly error message is more appropriate. Also note that you are the only person who has made "new" an issue. I don't care about new, I care about correct. However a much larger category of error messages, particularly in server side programming, which you were claiming as "user generated" are in fact entirely the fault of the programmer and are better left untouched without obfuscation (and even in the case where they are caused by the user you damn well better be logging the actual reason for when you screw up) Note that I specifically listed that as a case where actually a friendly error message is more appropriate. Also note that you are the only person who has made “new” an issue. I don’t care about new, I care about correct.

However a much larger category of error messages, particularly in server side programming, which you were claiming as “user generated” are in fact entirely the fault of the programmer and are better left untouched without obfuscation (and even in the case where they are caused by the user you damn well better be logging the actual reason for when you screw up)

]]>