Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If you/they are going to 'fix' the error, then they will (should) be doing it at a point in the code where they already have that information at hand. You're assuming that the only reason to catch an error is to try to fix it. There are lots of other reasons, like ignoring it, changing the error message for a different audience, etc. If you think it's ok to just output an error message from a low level 3rd party module to the user of your software on the screen, then you've failed at creating usable software. If you don't use 3rd party modules (like CPAN modules) and all your users are programmers, and all of the users of your users (if you're writing modules that can be used by 3rd parties) are also programmers, then maybe you have an excuse. But I like the freedom to be able to decide how I want to handle different kinds of exceptions (escpecially if they have some kind of structured data) without having to resort to parsing every error message by hand. And the really nice thing about Exception::Class is that if you don't care about all the extra goodies it provides, then just ignore it an treat it like a string and leave the rest of us alone. -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier In reply to Re^10: eval to replace die?
by mpeters
|
|