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

[Rick Welykochy]

MJ Ray wrote:

> Rick Welykochy <rick at praxis.com.au> wrote: [...]
>> To stop this problem once and for all from ever occurring again,
>> catch all errors. To catch all errors and thus produce the correct
>> headers for EVERY Koha script, use exception handling. Works a treat :)
> 
> What we should do is make the errors prettier.  We should probably use
> CGI::Carp qw(fatalsToBrowser); - is that OK by everyone and do we need
> this only in C4::Output or in all cgi-bin scripts?

This is okay, but it does present a security concern, since
internal details of the Perl environment and MySQL could be revealed
with the dumped errors.

In my experience, system and internal errors are for "programmers
eyes only".

Would you want these errors to be displayed on the browser of an
OPAC user?


> I don't think exceptions are the way to go.  Read the top of perl's
> exceptions library:
> [...]
> # This library is no longer being maintained, and is included for backward
> # compatibility with Perl 4 programs which may require it.
> #
> # In particular, this should not be used as an example of modern Perl
> # programming techniques.
> [...]

Erm ... the above does not apply to Perl's built-in error handling.
Fatal errors are raised as exception via die and can be caught via eval.
Exceptions (i.e. fatal error processing) are indeed very modern Perl
programming techniques.



> Also, we're never going to catch all errors.  Sysadmins and users
> sometimes do surprising things, like transposing fields in the
> configuration, or installing new firewalls.

The built-in exceptions in perl are fine and are actually the
correct way to handle disparate errors that can anywhere inside
a perl application.

All errors can be caught this way, except for calls to exit(). Then
again, I would question any library or internal function taht calls exit(),
wouldn't you?

Here is how it works:

http://praxis.com.au/demo_error.pl

    The above produces the classic 500 Internal Server Error

http://praxis.com.au/demo_error.pl/no

    The above produces a correct result, no error.

http://praxis.com.au/demo_error.pl/trap

    The above causes an error (division by zero) but the user is
    only told that an error occurred.

http://praxis.com.au/demo_error.pl/show

    The above causes the error *and* shows a stack trace and
    environment dump. This can be enabled via a constant or
    Koha Config item (for example, during development or debugging)

Finally, to show that other errors like an IO error can
be handled in the same way:

http://praxis.com.au/demo_error.pl/showio


View the script source here: http://praxis.com.au/demo_error.txt
and the demo library here:   http://praxis.com.au/demo_error_lib.txt

I have used these techniques in large-scale ecommerce systems
and they work fine. Errors are caught by the wrapper as shown in
the code, and information about the error can be sent to an
internal staff member. Very little needs to be shown via the browser
unless it is dev/debugging time.

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.