MJ Ray wrote:
So by exceptions, you did not mean exceptions as such. Thanks for clarifying.
I meant fatal errors raised as exceptions via die(). This is how all fatals are handled in perl.
The manual entry for die suggests using Carp, which is what I suggested too. Using core perl modules seems far safer than relying on everyone remembering on wrapping everything that can go wrong in an appropriate eval{}. Sod's law says that an error would occur outside the eval{} anyway.
The "perldoc -f die" entry does not mention Carp. Carp provides better formatting of message sent via die: "The Carp routines are useful in your own modules because they act like die() or warn(), but with a message which is more likely to be useful to a user of your module." i.e. Carp is for terminating (via croak or confess) or warning (via carp or cluck) in a "nicer way", to be used for the benefit of CLIENTS of the software you are writing.
I'm slightly scared that you have re-invented that wheel and then used that re-invention in large-scale ecommerce systems. Why aren't you using the Carp modules or something based on them?
Carp does not provide exception catching. That has to be implemented by the application writer. Carp does not provide the functionality I have demonstrated at http://praxis.com.au/demo_error.pl/showio which intercepts an IO error, and displays detailed information to the browser in addition to notifying the sysadmin. The demo_error.pl example intercepts ALL errors and works for all perl applications :) cheers rickw -- _________________________________ Rick Welykochy || Praxis Services The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. -- Douglas Adams on Windows '95.