Why I’m not leaving Python for Go

Re:Why I’m not leaving Python for Go by to3m on Monday September 24, 2012 @07:43AM (#4564115)

My point was that programmers are happy to push the "error" handling off to some other part of the code, far away from the point at which the "error" arises, in some place that usually has no real idea how to handle it, or present it, or what have you. All as if there's some default privileged path where everything is running normally, and then this occasional strange special case that crops up now and again. Exceptions explicitly encourage this style of programming - keeping the error handling apart from the main logic is their very purpose.

But were programmers to consult the history of their compiler's output (representative summary: "ERROR ... ERROR ... FAILED ... WARNING ... ERROR"), it would be obvious that in fact errors are highly likely, even if you know what you're doing. So what makes the error case different from all the other cases?

[ Parent | on HN ]

Re:Why I’m not leaving Python for Go by barrkel on Monday September 24, 2012 @10:00PM (#4568131)

Errors in compilation are not exceptional; one of the main reasons to use a compiler rather than an interpreter is specifically to search for errors. So exceptions are a poor fit.

You're quite right that exceptions promote giving up control to a higher level. And that's the right thing to do for exceptional situations. The ultimate higher level is the programmer who's going to have to fix the bug, or the admin who needs to fix the configuration problem - because they are the two main classes of errors for which exceptions are great. (The third class is a logical abort, and depending on the language and how good its idioms support exceptions, this may or may not be good practice.)

You get rich information about the error, including a call stack, the ongoing operation gets cancelled as soon as it occurs rather than muddling onwards and causing more damage. If you can foresee the error such that you can write an error handler, using the method that throws exceptions is probably not the right one - unless it's unavoidable owing to race conditions, or impoverished libraries.

[ Parent | on HN ]