[cgiapp] Re: CGI Error handling

[Mark Stosberg <suppressed>]

On 2003-11-02, Cees Hek <suppressed> wrote:
> Quoting Mark Fuller <suppressed>:
>
>> What's a good way to abort normal processing and display a simple error
>> message?
>> 
>> What I'd like to have is some way to abort the run-mode method, in
>> mid-stream, and let another one take over. Is there any way to do this?
>
> Inside your runmode just return the results of another runmode...  Here is some
> pseudocode
>
> sub my_runmode {
>   my $self = shift;
>
>   if (mysql_call_failed) {
>     return $self->error_runmode($mysql_error_message);
>   }
>
>   ...
> }
>
> sub error_runmode {
>   my $self = shift;
>   my @errors = @_;
>
>   my $template = new HTML::Template(filename => 'error.tmpl');
>
>   $template->param(errors => suppressed);
>   return $template->output()
> }

This is what I do as well and I'm happy with it. If your run mode
calls a subroutine, and that subroutine has a problem, things get a
little more complicated, since the subroutine could signal that it has
an error by returning 'undef', some kind of error message, or just
dying.

If the subroutine might die, you could trap that in your run mode:

	eval{ $result = _my_tricky_sub() };
    return $self->error_runmode($@) if $@;

Generally, I like the design philosophy of detecting errors at a low
level,  but handing them at a high level. The above design gives you
more flexibility to handle errors differently depending on the context.

For example, perhaps you want to run the same tricky subroutine from a
cron script, where returning an error message as HTML doesn't make
sense.

	Mark

--
http://mark.stosberg.com/




---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed