Rick Welykochy <rick@praxis.com.au> wrote:
The "perldoc -f die" entry does not mention Carp. [...]
That's strange. It does in perl 5.8.8: "See also exit(), warn(), and the Carp module."
Carp provides better formatting of message sent via die: [...] 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.
And what does that script do when it intercepts it? It displays a better-formatted system error, dumping lots of internal data! Using a Carp is more general and would reveal less about the internals by default. Also, what happens if your script contains an error outside the eval{}? Sod's law says that some errors would occur outside the eval{} anyway. Putting a use Carp at the top handles the whole script. Only a perl core problem would derail that and that's beyond our powers. If we can recover gracefully from a resource failure, we should test for it and handle it in the code, as usual, not get into the half-hidden couplings of throwing and catching exceptions. (Look up about exceptions and coupling in programming/software engineering texts and journals if you've not noticed this problem. I expect someone has posted something with a title like "Exceptions considered harmful" on the web by now.) If the exception is a programming error, how do you handle that? If it's in a module, it would be far better if the module routine returned an error code instead of die()ing. If it's in the main code, there's not much we can do better than output a bug report. Our current error output (the server's default 500) can be improved. I feel that die()ing, whether on our own request or forced by perl, should only be handled to produce saner output for a bug report, which is what Carp does. die()ing shouldn't be a part of normal operation. Hope that explains, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/