Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working through the book "Head First Python" (it's my language to learn this year) and I got to a section where they argue about two code techniques: Defensive coding vs Exception handling. Here is a sample of the Python code:

# Defensive Coding
for eachLine in open("../../data/sketch.txt"):
    if eachLine.find(":") != -1:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

# Exception handling        
for eachLine in open("../../data/sketch.txt"):
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

The first example deals directly with a problem in the .split function. The second one just lets the exception handler deal with it (and ignores the problem).

They argue in the book to use exception handling instead of defensive coding. The argument is that the exception code will catch all errors, where defensive coding will only catch the things you think about (and you miss the corner cases). I have been taught to code defensively, so my intial instinct was to code defensively, but their idea is interesting. I had never thought of using the exception handling to deal with cases.

Which of the two is the generally considered the better practice?

share|improve this question
That section in the book is not smart. If you are in a loop and you are throwing exceptions over and over its very costly. I tried to outline some good points of when to do this. – Jason Sebring Mar 11 '12 at 5:29
Just don't fall into the "file exists check" trap. File exists != has access to file, or that it will exist in the 10 ms it takes to get to my file open call, etc.… – Billy ONeal Mar 11 '12 at 6:00
Exceptions are thought of differently in Python than in other languages. For instance the way to iterate through a collection is to call .next() on it until it throws an exception. – WuHoUnited Mar 11 '12 at 14:25
3 That's not entirely true about Python. I don't know the specifics, but the language has been built around that paradigm, so exception throwing isn't nearly as costly as in other languages. – Izkata Mar 12 '12 at 0:51
That said, for this example, I would use a guard statement: if -1 == eachLine.find(":"): continue, then the remainder of the loop wouldn't be indented, either. – Izkata Mar 12 '12 at 0:54
up vote 51 down vote accepted

In .NET, it is common practice to avoid the overuse of Exceptions. One argument is performance: in .NET, throwing an exception is computationally expensive.

Another reason to avoid their overuse is that it can be very difficult to read code that relies too much on them. Joel Spolsky's blog entry does a good job of describing the issue.

At the heart of the argument is the following quote:

The reasoning is that I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:

1. They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs.

2. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.

Personally, I throw exceptions when my code can't do what it is contracted to do. I tend to use try/catch when I'm about to deal with something outside of my process boundary, for instance a SOAP call, a database call, file IO, or a system call. Otherwise, I attempt to code defensively. It's not a hard and fast rule, but it is a general practice.

Scott Hanselman also writes about exceptions in .NET here. In this article he describes several rules of thumb regarding exceptions. My favourite?

You shouldn't throw exceptions for things that happen all the time. Then they'd be "ordinaries".

share|improve this answer
here's another point: if exception logging is enabled application-wide, it's better to use exception only for exceptional conditions, not for ordinaries. Otherwise the log will become cluttered and the real error-causing reasons will be obscured. – rwong Mar 11 '12 at 4:12
Nice answer. Note though exceptions have a high performance hit on most platforms. However, as you will have noted with my comments on other answeres, performance is not a consideration in the case of deciding a blanket rule for how to codify something. – mattnz Mar 11 '12 at 4:42
The quote from Scott Hanselman better describes the .Net attitude towards exceptions than "overuse". Performance is frequently mention, but the real argument is the inverse of why you SHOULD use exceptions - it makes the code harder to understand and deal with when an ordinary condition results in an exception. As for Joel, point 1 is actually a positive (invisible means that code shows what it does, not what it doesn't), and point 2 irrelevant (you are already in an inconsistent state, or there shouldn't be an exception). Still, +1 for "can't do what it has been asked to do". – jmoreno Mar 11 '12 at 17:14
+1. I like the idea of exception handling, but I try to use error checking as the first option, not only for avoiding "exception laziness" (using try..catch as a replacement for a better program logic), but also because it avoids some dangerous bugs: e.g. at my workplace the function (not python) that queries the DB returns false (no exception) when the SQL query fails, and if you try to you use an uninitialized result set it throws an exception, but maybe you have it "initialized" of previous use (e.g. when it fails in the middle of a loop), so instead of failing you are using the wrong data. – Alberto Martinez Mar 11 '12 at 17:28
While this answer is fine for .Net, it isn't very pythonic, so given that this is a python question, I fail to see why Ivc's answer hasn't been voted up more. – Mark Booth Mar 13 '12 at 13:57

In Python in particular, it is usually considered better practice to catch the exception. It tends to get called Easier to Ask for Forgiveness than Permission (EAFP), compared to Look Before You Leap (LBYL). There are cases where LBYL will give you subtle bugs in some cases.

However, do be careful of bare except: statements as well as overbroad except statements, since they can both also mask bugs - something like this would be better:

for eachLine in open("../../data/sketch.txt"):
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
share|improve this answer
As a .NET programmer, I cringe at this. But then again, you people do everything weird. :) – Phil Apr 4 '14 at 19:24
This is exceptionally frustrating (pun not intended) when APIs are not consistent about which exceptions are thrown under which circumstances, or when multiple different kinds of failures are thrown under the same exception type. – Jack Dec 31 '15 at 20:34

A Pragmatic Approach

You should be defensive but to a point. You should write exception handling but to a point. I'm going to use web programming as an example because this is where I live.

  1. Assume all user input is bad and write defensively only to the point of data type verification, pattern checks and malicious injection. Defensive programming should be things that can potentially happen very often that you cannot control.
  2. Write exception handling for networked services that may fail at times and handle gracefully for user feedback . Exception programming should be used for networked things that may fail from time to time but are usually solid AND you need to keep your program working.
  3. Don't bother to write defensively within your application after the input data has been validated. Its a waste of time and bloats your app. Let it blow up because its either something very rare that isn't worth handling or it means you need to look at step 1 and 2 more carefully.
  4. Never write exception handling within your core code that is not dependent on a networked device. Doing so is bad programming and costly to performance. For example writing a try-catch in case of out of bounds array in a loop means you didn't program the loop correctly in the first place.
  5. Let everything be handled by central error logging that catches exceptions in one place after following the above procedures. You cannot catch every edge case as that may be infinite, you only need to write code that handles expected operation. That's why you use central error handling as the last resort.
  6. TDD is nice because in a way is try-catching for you without bloat, meaning giving you some assurance of normal operation.

This is from experience working in large team scenarios.

An Analogy

Imagine if you wore a space suit inside the ISS ALL the time. It would be hard to go to the bathroom or eat, at all. It would be super bulky inside the space module to move around. It would suck. Writing a bunch of try-catches inside your code is kind of like that. You have to have some point where you say, hey I secured the ISS and my astronauts inside are OK so its just not practical to wear a space suit for every scenario that could possibly happen.

share|improve this answer
The problem with Point 3 is it assumes the program, and programmers working on it, are perfect. They aren't, so it's best program defensively with these in mind. Approriate amounts at key juncture can make the software far more reliable than the "If the inputs are checked everythings perfect" mentality. – mattnz Mar 11 '12 at 7:34
that's what testing is for. – Jason Sebring Mar 11 '12 at 15:59
Testing isn't a catch all. I have yet to see a test suite that has 100% code and "environmental" coverage. – Marjan Venema Mar 11 '12 at 16:57
see point 5 for reference – Jason Sebring Mar 11 '12 at 17:06
@emeraldcode : Do you want a job with me, I would love to have someone on the team that always, with exception, tests every permutation of every edge case the software will ever execute. Must be nice knowing with abosoluite certainty that your code is perfectly tested. – mattnz Mar 11 '12 at 19:12

The book's main argument is that the exception version of the code is better because it will catch anything that you might have overlooked if you tried to write your own error checking.

I think this statement is true only in very specific circumstances - where you don't care if the output is correct.

There is no doubt that raising exceptions is a sound and safe practice. You should do so whenever you feel there's something in the current state of the program that you (as a developer) cannot, or don't want to, deal with.

Your example, however, is about catching exceptions. If you catch an exception, you're not protecting yourself from scenarios you might have overlooked. You are doing precisely the opposite: you assume that you haven't overlooked any scenario that might have caused this type of exception, and therefore you're confident that it's alright to catch it (and thus prevent it from causing the program to exit, as any uncaught exception would).

Using the exception approach, if you see ValueError exception, you skip a line. Using the traditional non-exception approach, you count the number of returned values from split, and if it's less than 2, you skip a line. Should you feel more secure with the exception approach, since you may have forgotten some other "error" situations in your traditional error check, and except ValueError would catch them for you?

This depends on the nature of your program.

If you're writing, for example, a web browser or a video player, a problem with inputs should not cause it to crash with an uncaught exception. It's far better to output something remotely sensible (even if, strictly speaking, incorrect) than to quit.

If you're writing an application where correctness matters (such as business or engineering software), this would be a terrible approach. If you forgot about some scenario that raises ValueError, the worst thing you can do is to silently ignore this unknown scenario and simply skip the line. That's how very subtle and costly bugs end up in software.

You might think that the only way you can see ValueError in this code, is if split returned only one value (instead of two). But what if your print statement later starts using an expression that raises ValueError under some conditions? This will cause you to skip some lines not because they miss :, but because print fails on them. This is an example of a subtle bug I was referring to earlier - you would not notice anything, just lose some lines.

My recommendation is to avoid catching (but not raising!) exceptions in the code where producing incorrect output is worse than exiting. The only time I'd catch an exception in such code is when I have a truly trivial expression, so I can easily reason what may cause each of the possible exception types.

As to the performance impact of using exceptions, it is trivial (in Python) unless exceptions are encountered frequently.

If you do use exceptions to handle routinely occurring conditions, you may in some cases pay a huge performance cost. For example, suppose you remotely execute some command. You could check that your command text passes at least the minimum validation (e.g., syntax). Or you could wait for an exception to be raised (which happens only after the remote server parses your command and finds a problem with it). Obviously, the former is orders of magnitude faster. Another simple example: you can check whether a number is zero ~10 times faster than trying to execute the division and then catching ZeroDivisionError exception.

These considerations only matter if you frequently send malformed command strings to remote servers or receive zero-valued arguments which you use for division.

Note: I assume you would use except ValueError instead of the just except; as others pointed out, and as the book itself says in a few pages, you should never use bare except.

Another note: the proper non-exception approach is to count the number of values returned by split, rather than search for :. The latter is far too slow, since it repeats the work done by split and may nearly double the execution time.

share|improve this answer

As a general rule, if you know a statement could generate an invalid result, test for that and deal with it. Use exceptions for things you do not expect; stuff that is "exceptional". It makes the code clearer in a contractual sense ("should not be null" as an example).

share|improve this answer

Use what ever works well in..

  • your chosen programming language in terms of code readability and efficiency
  • your team and the set of agreed code conventions

Both exception handling and defensive programming are different ways of expressing the same intent.

share|improve this answer

Basically Exception handling supposed to be more appropriate for OOP languages.

Second point is the performance, because you don't have to execute eachLine.find for every line.

share|improve this answer
-1: Performance is an extremely poor reason for blanket rules. – mattnz Mar 11 '12 at 4:39
No, exceptions are completely unrelated to OOP. – Pubby Mar 11 '12 at 4:42

I think defensive programming hurts performance. You should also catch only the exceptions you are going to handle, let the runtime deal with the exception you don't know how to handle.

share|improve this answer
Yet anotehr -1 for worring about performance over readablity, maintainablity bla bla bla. Performance is not a reason. – mattnz Mar 11 '12 at 4:41
May I know why are you running around distributing -1s without explaining? Defensive programming means more lines of code, that means poorer performance. Anybody care to explain before shoting down the score? – Manoj Mar 11 '12 at 16:23
@Manoj: Unless you've measured with a profiler and found a block of code to be unacceptably slow, code for readability and maintainability far before performance. – Daenyth Mar 11 '12 at 17:28
What @Manoj said with the addition that less code universially means less to work on when debugging and maintaining. The hit on developer time for anything less that perfect code is extremely high. I am assuming (like me) you don't write perfect code, forgive me if I am wrong. – mattnz Mar 11 '12 at 19:08
Thanks for the link - Interesting read that I have to agree with it, to a point... Working on a life critical systems, as I do "The system printed the stack trace, so we know exactly why those 300 people died needlessly....." isn't really going to go down too well in the witness stand. I suppose it's one of those things where every situation has a different appropriate response. – mattnz Mar 12 '12 at 2:30

protected by gnat Apr 4 '14 at 18:32

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.