Rick Welykochy <[EMAIL PROTECTED]> 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/ _______________________________________________ Koha-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/koha-devel
