MJ Ray wrote:
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.
I think you are taking my published example too literally: it just shows what can be done with exception processing. And dumping that stuff is very handy during software development. Why do you think Java does similar? It makes debugging much saner. In a production environment, dumping all that stuff to the browser is disabled. Right?
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.
This is true. Any exceptions raised outside the eval are of course not caught. I don't know how good CGI::Carp is at catching "compile-time" or startup errors. Some experimentation may be required. But look at it this way. During development anything can and often does happen. The production environment is a different beastie. If your application cannot make it to the eval { ... } that wraps a script, the application and its attendant services are going down bigtime.
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.)
But this is exactly how CGI::Carp works. By catching exceptions. And it is probably a reasonable and simple solution for Koha. But it will be hard to turn CGI:Carp on in development and off in production. Remember: most of the errors we see on the Koha list from library users are during installation and deployment, not during actual production. Detecting and listing errors is not and should hopefully not be required in production, unless the code is flawed. It is glib to say "Exceptions considered evil". Yes, I agree that code sprinkled willy-nilly with exception handling blocks can become tedious and a maintenance nightmare. That is not what is being discussed here. You've "raised" a red herring, so to speak. Horses for courses: CGI::Carp as well as my published solution use ONE single eval to catch all errors that may come from the application. That's all. Just one. Regarding error codes vs. exceptions. Each has its place. I prefer error codes for simple, recoverable situations and exceptions for fatal errors. When an error is fatal, i.e. like an assertion failure or hardware fault, there is absolutely no point in continuing execution of the code: program abort is about all that can be done, since the state of things after the fatal error is undefined. Let's not lose sight of why this thread was opened. Myself and many many other Koha installers have been stymied and mystified when an error occurs and all they see in the error_log is "Unexpected end of script headers", or we are offered the script as a download. Sometimes we have had to run the script in the shell to see what the error message was. This can be easily solved by using CGI::Carp or some other exception catch, which ensures that the correct and complete headers are written to the client. I've used CGI::Carp with great success. I roll my own exception handler when I need to auto-log the error and perhaps email a sys admin that an unexpected problem has occurred. The Koha developers can decide how much intervention and reportage is required when a fatal error occurs. CGI::Carp would be a vast improvement over nothing. 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.