in reply to Re (tilly) 7: out of loop
in thread out of loop

With the code I have to maintain, I am overjoyed to see open FILE, "file" or die;. Most of the time it is just open FILE "file";.

Error handling is not a one size fits all proposition. You scale it with the size and importance of your program, and severity and likelihood of the error. If I am writing a one timer, I might not check return values at all; other times, I am going to be as paranoid as possible, checking and double checking everything I can. It is a matter of using the correct amount of error handling for your situation, instead of applying it with a trowel to get as much in there as you can.

As for burning the midnight oil, I have had to wade through hard to maintain, overly elaborate, and downright buggy error handling schemes at odd hours, where a simple or die; would have told me what I needed to know immediately. The developer responsible refused to acknowledge there was such a thing as too much error handling, or that its complexity made his code less reliable, not more.

We shouldn't be advocating error handling for error handling's sake alone. It is a judgement to be made based on a number of program specific factors. As for code without context, like the snippets offered here, determinations about the "correct" level of error handling can only be made on the coarsest of levels.

Replies are listed 'Best First'.
Re (tilly) 9: out of loop
by tilly (Archbishop) on Apr 01, 2001 at 04:15 UTC
    In case it is obvious, the claim that error handling is something that you do appropriately to the task is one that I disagree with. There is virtually no script that I write that doesn't have error handling somewhere. Whether 5 lines or 5000 I have it in.

    That said, I think we all have seen elaborate and stupid error handling. Error handling - like everythingthing else in programming - is not an ideal good in and of itself. It serves a goal. That goal is that if your program does not do what you want, that it will let you know that with enough useful information that you can fix the problem. If you are reporting non-errors, or failing to report real ones, or failing to be useful - all are bad.

    It is important because code is inherently buggy. A claim that I have heard is that there is an average of one bug per 10 lines written. Dunno if that is true. (I always suspect claims with conveniently round numbers in them.) But certainly the real number is very high. Your error handling is not where you want those bugs to be. Therefore you make your scheme very simple, and concentrate on real errors.

    One of which, I guarantee you, is going to be the failure to open a file you expected to be able to open...

[reply]

In Section Seekers of Perl Wisdom