Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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"):
    try:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
    except:
        pass

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
5  
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
3  
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. blogs.msdn.com/b/jaredpar/archive/2009/04/27/… –  Billy ONeal Mar 11 '12 at 6:00
4  
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
2  
@emeraldcode.com 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

8 Answers 8

up vote 41 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
1  
Spot on! Nice answer! –  k25 Mar 11 '12 at 4:03
2  
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
2  
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
1  
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  
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

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 it just means you need to test step 1 and 2 better.
  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 catching an out of bounds array. Your code should be tested enough to never do that.
  5. Let everything be handled by central error logging that catches exceptions in one place after following the above procedures. You either screwed up in one of the steps or this is just something in your core environment you could not control and your program should fail.

This is from experience working in large teams on large projects and being bitch-slapped when not following these practices.

share|improve this answer
2  
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
2  
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
1  
@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

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

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

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"):
    try:
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        pass
    else:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
share|improve this answer
11  
+1 for a "pythonic" answer. –  Kyle Hodgson Mar 13 '12 at 17:54
2  
As a .NET programmer, I cringe at this. But then again, you people do everything weird. :) –  Phil Apr 4 at 19:24

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
6  
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
2  
@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
2  
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

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
6  
-1: Performance is an extremely poor reason for blanket rules. –  mattnz Mar 11 '12 at 4:39
2  
No, exceptions are completely unrelated to OOP. –  Pubby Mar 11 '12 at 4:42

protected by gnat Apr 4 at 18:32

Thank you for your interest in this question. Because it has attracted low-quality answers, 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.