Do you like starting debugging without having a clue which
file you had problems on, or what helpful information was
in $!? How about your co-workers?
For these reasons and more, this is something that I feel
extremely strongly on. I do not like working with code
written by people who did not understand that this matters.
I do not want to depend on people who do not appreciate
this. Not knowing that trying to trap good error messages
is important is one thing, but refusing to learn is a
fireable offence in my books.
(And yes, the strength that I put into that statement
does reflect a few very miserable late nights that
I do not want to repeat. Ever.)
This was an illustrative snippet, to show how die could used to exit a loop. As such, I simplified a number of things, like no shebang, no use strict, not all the variables are initialized, and yes, limited error handling.
Had this been a real program, it would have used my home grown alarm object, which checks $!, $?, and $@, builds a meaningful error string, logs it to a file with a timestamp, sends email, and dies as necessary. This same object I proselytize within my company, much the same way you are doing now.
Had I included all that extraneous detail in my post, I fear the point would have been lost. And given it was essentially a "by the way" post, it would have required more effort than warranted to make it as explicit as you might like.
So while I understand the reasons for your strongly stated response, I believe it misplaced.
Couldn't you have just included an example snippet of what
it would have looked like and then just included a note
that the object you called here is a home-built
I find that people learn style from what are meant as
off-hand snippets, and so I think it is important that
everything from pseudo-code on up always at least
acknowledge the importance of testing for and dealing
with errors. I would prefer that people think, Geez,
that tilly is anal about error checking! than
accidentally encourage (if only by omission) people to