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. | [reply]
[d/l]
[select] |
| [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] |
