--As of February 21, 2010 1:43:58 PM +1300, Lutz Gehlen is alleged to have
said:
Therefore I would like to define my error messages in some sprintf
format way at a central place and use these templates when the time
has come. I have written a module Exception::Class::EasyThrow that
does this. However, I still have not published it. The reason is
that I have the feeling that I don't know much about how to deal
with exceptions in general and I wonder: If everybody would have my
problem then there should be something on the CPAN already. And if
other people don't have my problem how do they deal with the issues
I have mentioned above? That's my first question.
Personally, I use a system somewhat like that, but I don't expect that
class to be general. If the point is that all exceptions are consistent in
a project, I expect that class to be unique to the project. (And I quite
often won't make the messages themselves too detailed: The exception says
where it was thrown, so I use that to track where the problem is. The
message is just for decoration if something were to get through to a user.
It shouldn't be actually _used_ for anything.)
2) My second question is how thorough I should be about throwing
exceptions. Ideally, I would think that it should not only be
impossible that my module produces wrong results, but it should also
be impossible to trigger an internal Perl error within my module.
All the situations in which this would happen should be checked
beforehand and a proper exception should be thrown. However, this
goal raises several questions. To perform this thorough checks takes
a lot of development time and possibly also quite some execution
time. If I want to read in a long list of numbers, should I really
check that also the 3972nd one passes a looks_like_number test? In
general, should I really spend a lot of development and execution
time on checking input that no sane user would provide? On the other
hand, do I really want to claim to be able to anticipate every sane
scenario that a user might come up with?
Apart from that, is it really desirable to avoid internal perl
errors in any case? If Perl would die with "Division by 0" is it
necessary to throw an exception a bit earlier which says "Naughty
naughty! If I wouldn't have checked, perl would die with division by
0 in a moment."? However, what if perl bails out much later? Then
debugging might be much easier when the error is detected right
away.
Mostly, what you are likely think of as 'internal Perl errors' here _are_
exceptions, in a sense. For instance, perl doesn't _die_ when it hits
division by 0, it die()'s. (Or some equivalent.) If someone using your
code is expecting exceptions and therefore calling your code in eval
blocks, that will be caught. (In other words: 'eval { say 1/0; } or say
"I had an error.";' will return 'I had an error.', not a 'Division by 0'
error.)
So, basically, don't try to overdo it. Perl will handle some things
appropriately for you. One of the basic rules I learned ages ago was
'Don't test for a condition you aren't going to handle.' Throw an
exception if you expect the calling program to be able to handle the
exception and recover in some way. If that's not really possible, it's
appropriate to die, and tell the user they're insane. (Or, at least, that
they've driven _you_ insane.)
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
