Exceptions (2003)
joelonsoftware.com
Exceptions (2003)
1–10 of 93 posts
Re: Exceptions (2003)
#2"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.
Re: Exceptions (2003)
#3"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 code. As such, it is an exceptionally good software development tool.
Re: Exceptions (2003)
#4> [as an alternative to exceptions] "It is true that what should be a simple 3 line program often blossoms to 48 lines when you put in good error checking, but that's life
Was he being serious? I'd rather not wade through all that error checking cruft to see normal flow. Exceptions (or goto) don't create buggy hard to read programs, people do.
Re: Exceptions (2003)
#5"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…
I agree. Exceptions are a very useful tool, when used appropriately. Problem is, they're not used very appropriately.
Re: Exceptions (2003)
#6If you're catching exceptions all over the place, or worse using them for flow control as part of normal operations, you're doing it wrong. Exceptions should indicate a major error that you can't easily recover from and as such should be caught and logged at the top of the stack, i.e. the main thread run method or request handler.
When used that way, they give you very useful information as to what went wrong and where, while making your program more robust and resilient to errors. We've found this to be the case time after time at https://starthq.com, which runs on Node but uses fibers via https://github.com/olegp/common-node.
Re: Exceptions (2003)
#7Some Haskellers treat exceptions as something that you only use if the program has entered an unrecoverable condition and needs to crash.
Re: Exceptions (2003)
#8I don't use exceptions for normal flow. I use them for errors.
While it is true that exceptions create innumerable code paths through a function, RAII makes that manageable. If you're not taking advantage of RAII in your C++ code, you might as well be writing C code.
Re: Exceptions (2003)
#9"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…
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
(And yes, I know there are edge'ish cases were I'd miss some data here)
Re: Exceptions (2003)
#10Exactly fits the philosophy of Google Go - http://blog.golang.org/error-handling-and-go
I think his point of there being easy syntax for multiple returns is critically important to make this sort of error handling non annoying - which Go does remarkably well.
I think this factor has a lot to contribute to the fact that you get the warm fuzzy feeling after your code compiles. You feel confident that you have already handled all the error cases (that you care about) in your code.
EDIT - Obligatory nitpick accepted. ;)