Joshua Chamas wrote:
> Genearlly, you just have a ErrorDocument that covers 500 internal
> server errors, and tell the end user something generic. These
> kinds of die() errors are fatal system errors so perhaps the
> end user should not see them anyway, else you could just trap
> the error in an eval{} and look at $@ normally.
I was thinking more along the lines of using die() as a kind of
exception-throwing mechanism, but as you point out this is conceptually
flawed since die() is meant for serious unrecoverable errors.
The main reason I wanted it is because DBI is much nicer to use (laziness
being, of course, one of the virtues) with RaiseError => 1, but then any
problem with the database results in a die() that seems untrappable (at
least in the way I want to do it). This is fine when one is talking about,
say, a SELECT containing a syntax error, which is a serious problem and
deserves a 500.
However, in the application I'm currently working on almost all of the
business logic is carried out in custom PostgreSQL server-side functions
which raise exceptions such as "insufficient funds." I like to put a lot of
sanity-checking in database triggers, and so either one has to duplicate
much of that code in Perl (time-consuming and error-prone) or one has to
trap the exceptions and handle them differently to generic database errors.
I eventually discovered DBI's HandleError mechanism, which allows me to give
it a reference to a subroutine that it calls instead of dying. This iis the
perfect solution to my problem, since I can trap the server-side exceptions,
parse the DBI error message, and either produce nice output for the user or
give a 500.
By the way, not only is Apache::ASP by far the best implementation of
embedded Perl available (and I've tried most of them), but the documentation
is extensive and the support you give its users is top-notch.
Congratulations on a superb job.
Regards,
Ross Thomas
P.S. In the documentation of XMLSubsMatch you might want to mention that
using the regular expression "my:.+" is an exceptionally bad idea ;) I
must've been having a brain freeze...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
