[Koha-devel] Re: FAQ: Why am I prompted to save a .pl file? was: Problems adding a biblio...

[Rick Welykochy]

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.