die problem in mod_perl

Hi

I have an eval block in my code which handles an error by calling a routine.
This does various things - like email me the error. It also prints a user
friendly message to the browser. This is all fine.

Then I want to stop the script executing any further and ideally to write to
the server error logs. So the last line of my error handling routine is:
die $error_message.

This does write to the log and terminates the script execution. BUT - it
also causes Apache to output to the browser the standard "The server
encountered an internal error or misconfiguration and was unable to complete
your request...." message, which I don't want as I've already printed my own
user friendly message.

How can I stop this behaviour?

with thanks

Kropotkin
--
View this message in context: http://www.nabble.com/die-problem-in-mod_perl-tp19462854p194 62854.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: die problem in mod_perl

On Fri, Sep 12, 2008 at 3:46 PM, kropotkin wrote:
> Then I want to stop the script executing any further and ideally to write to
> the server error logs. So the last line of my error handling routine is:
> die $error_message.

Make that:

print STDERR $error_message;
return OK();

- Perrin

Re: die problem in mod_perl

Hi Perrin

Thanks. The problem is that all this is happening in a function which has
itself been called by another function and this in turn by another. So; if I
do:

return "OK";

the calling function gets this not Apache. True; I could pass return values
back up the chain and at the top-level if there was a problem do return "OK"
there to cancel execution without generating a 500 error but this would be a
pain to manage.

I found an easier solution - which may of course not be the 'best' one: I
still call die in my custom error handling routine which generates a 500
error. But I've used the Apache ErrorDocument directive to kill of the
default error message and replace it with my own (I found out it takes text
as well as a file). I just pass it a period, and that's it.

Thanks again

regards
Kropotkin






Perrin Harkins wrote:
>
> On Fri, Sep 12, 2008 at 3:46 PM, kropotkin
> wrote:
>> Then I want to stop the script executing any further and ideally to write
>> to
>> the server error logs. So the last line of my error handling routine is:
>> die $error_message.
>
> Make that:
>
> print STDERR $error_message;
> return OK();
>
> - Perrin
>
>

--
View this message in context: http://www.nabble.com/die-problem-in-mod_perl-tp19462854p194 64258.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: die problem in mod_perl

On Fri, Sep 12, 2008 at 5:14 PM, kropotkin wrote:
> True; I could pass return values
> back up the chain and at the top-level if there was a problem do return "OK"
> there to cancel execution without generating a 500 error but this would be a
> pain to manage.

Then catch the die in an eval at a level where you can return OK to apache.

> I found an easier solution - which may of course not be the 'best' one: I
> still call die in my custom error handling routine which generates a 500
> error. But I've used the Apache ErrorDocument directive to kill of the
> default error message and replace it with my own (I found out it takes text
> as well as a file). I just pass it a period, and that's it.

That's not a good solution. What if there was an unexpected error in
some other code? You would never know.

- Perrin

Re: die problem in mod_perl

Hi Perrin

Thanks again. This is most helpful.

I've now wrapped the top level call in an eval block and that works fine.
Just one problem though - print STDERR is printing the message to the main
server error log not the virtual host error log. die printed it to the
virtual host error log. It doesn't really matter as only I not clients will
be looking at the log but it is a frustration.


regards

Kropotkin







Perrin Harkins wrote:
>
> On Fri, Sep 12, 2008 at 5:14 PM, kropotkin
> wrote:
>> True; I could pass return values
>> back up the chain and at the top-level if there was a problem do return
>> "OK"
>> there to cancel execution without generating a 500 error but this would
>> be a
>> pain to manage.
>
> Then catch the die in an eval at a level where you can return OK to
> apache.
>
>> I found an easier solution - which may of course not be the 'best' one: I
>> still call die in my custom error handling routine which generates a 500
>> error. But I've used the Apache ErrorDocument directive to kill of the
>> default error message and replace it with my own (I found out it takes
>> text
>> as well as a file). I just pass it a period, and that's it.
>
> That's not a good solution. What if there was an unexpected error in
> some other code? You would never know.
>
> - Perrin
>
>

--
View this message in context: http://www.nabble.com/die-problem-in-mod_perl-tp19462854p194 65331.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: die problem in mod_perl

On Fri, Sep 12, 2008 at 6:38 PM, kropotkin wrote:
> Just one problem though - print STDERR is printing the message to the main
> server error log not the virtual host error log. die printed it to the
> virtual host error log.

Yeah, that was bad advice. You should probably use Apache2::Log for
this instead:
http://perl.apache.org/docs/2.0/api/Apache2/Log.html

- Perrin

Re: die problem in mod_perl

Hi Perrin

I'll look at it. Thanks.

Kropotkin.



Perrin Harkins wrote:
>
> On Fri, Sep 12, 2008 at 6:38 PM, kropotkin
> wrote:
>> Just one problem though - print STDERR is printing the message to the
>> main
>> server error log not the virtual host error log. die printed it to the
>> virtual host error log.
>
> Yeah, that was bad advice. You should probably use Apache2::Log for
> this instead:
> http://perl.apache.org/docs/2.0/api/Apache2/Log.html
>
> - Perrin
>
>

--
View this message in context: http://www.nabble.com/die-problem-in-mod_perl-tp19462854p194 65537.html
Sent from the mod_perl - General mailing list archive at Nabble.com.