MJ Ray wrote:
Rick Welykochy <rick@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.