Hello everybody, I am writing this email to ask two general questions about throwing exceptions. Parts of them are not restricted to Perl and just reflect my general lack of knowledge about how to deal with exceptions in a professional way. So if you think "RTFM" when you read on, I am happy to be pointed to existing literature since at the moment I don't even really know what I am looking for.
1) The first question deals with how to throw exceptions properly. In projects which ask for a more sophisticated way than just carping or croaking I use Exception::Class. However, in both cases the error message has to be assembled when the error is thrown. I do not like that for three reasons. First, it makes the code to throw the exception long thereby drawing much attention when reading the code. Second, it tends to make the message texts inconsistent. Maybe I am too perfectionist here, but I don't like my package printing "Undefined variable foo." here and "Variable bar in not defined." there. Third a central error message definition area would make it easy to check if all exceptions are documented. 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. 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. I guess your answer to all these questions will be: It depends. However, my question is if there are any general guidelines how to decide what to check and what not (depending on my general security requirements) or do I have to perform some gut-feeling appraisal of efficiency vs. security? Sorry for the long text and thank you very much for your comments, Lutz
