|
in reply to Re (tilly) 5: out of loop
in thread out of loop
I probably could have, but I don't think it would have added value. When I write example code, I add detail where it is relevant to the thread, and remove it where it is not. How many times do you see a simple open FILE, "file" or die; in an snippet? To me, it is clear that is just a placeholder, showing, but not elaborating upon, the error handling one would normally expect.
In fact, my code started out with open FILE, $_ or die; and warn "Error!" if $@;. Perhaps I should have left it that way, making it clear the error handling was in fact a simplification, and not representative of what belongs in a real program. |
Re (tilly) 7: out of loop
by tilly (Archbishop) on Mar 31, 2001 at 23:45 UTC
|
How many times have I seen production code with
open FILE, "file" or die;? Far too often
to give the benefit of the doubt to anyone who writes that
in a snippet!
It doesn't take very many painful midnights debugging what
should be straightforward problems to develop that
attitude...(The mistakes were made before I arrived
there.) | [reply] |
|
|
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.
| [reply]
[d/l]
[select] |
|
|
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] |
|
|
