Hi Lutz, * Lutz Gehlen <lrg...@gmx.net> [2010-02-21 01:40]: > 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.
given that Exception::Class already provides a central place to define your exception hierarchy along with messages,… I don’t follow what it is that you need another central place for? > 2) My second question is how thorough I should be about > throwing exceptions. You don’t want to check each and every possibility. As you said, if nothing else, it might needlessly prevent clever uses of your code, and most of the time you don’t gain much anyway. > 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? There are basically two ways for errors to propagate: downward and sideways. • Downward propagation means you got something from the user, and you just passed it down through to something else without checking it. This is easy to debug: that’s what stack traces are for. Maybe the user passed something bad into your code and your code blew up. Then the error won’t be reported in their code, but a stack trace will tell them which call of theirs it was where they passed something nonsensical that caused your code to crash. • Sideways propagation means you processed a value in some way, and then used or returned the result without checking if it’s good. Eg. first (try to) you turn a filename into a filehandle, then you blindly pass the filehandle to a function. This is hard to debug. The value that caused the problem is not a value passed down directly, it is the result of some computation whose intermediate states do not show up in the stack trace. The trace doesn’t tell you why that bad value got to be bad in the first place. You have to step through the code in a debugger or add print statements to track what happened. I’m sure you can already imagine where this is going: basically, you should check your own intermediate computed values, to ensure you don’t propagate error conditions sideways between parts of your own code. But if you operate on user input directly, and the operation can blow up, you can leave that input unchecked for the purposes of error reporting. (You might of course still want to check it for other reasons, eg. security. That’s a different matter.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
