[Catalyst] "or die" replacement?

[apv]

It seems like there might be a disconnect about what die does in 
Catalyst.

If you call die in a controller it doesn't kill the application or halt 
processing.
It propagates an error (I don't know if it's an object or just plain 
text)
into the context, the $c.

So in your end controller you could have had all kinds of exceptions
and problems in the DB the template, whatever. They're all in
@{ $c->error }. And they can be erased with $c->error(0) so that
you can continue on with something you know to be sane like
a $c->response->body("No good, fire the developer!").

On Thursday, March 16, 2006, at 01:14  PM, Daniel McBrearty wrote:

> Not a catalyst app, but mod_perl - my current project has a small 
> "error" module that has a couple of methods :
>
> warn logs to the error file with the name of the calling code, but 
> lets the request carry on
> fatal logs and terminates the request without killing the process.
>
> From what I remember from Writing Apache Modules In perl and C, "die" 
> is a bit dodgy under mod_perl. The substitute is just to tell the 
> request to give up, it's a bad day.
>
> I never though of it, but either could easily extended to email me 
> without actually sending much more info than "you better look in the 
> logs, mate"
>
>
> On 3/16/06, Phil Mitchell <phil at 2people.org> wrote:
>
>
> On 3/15/06, Andreas Jellinghaus < aj at ciphirelabs.com> wrote:
>
>
> What are your recommendations, how should I replace
> my "or die" code? It is important to me to give
> some feedback to the user that something went wrong,
> and - to be sure - create a proper entry in some
> log file, e.g. apache error log (catalyst running
> with mod_perl inside apache).
>
>  
> It's a good question, and I'd like to see more examples of what people 
> do, and maybe a best practice. Instead of die, my app throws named 
> exceptions (cf. Exception::Class), which are easy to catch, and you 
> can provide appropriate error msgs to the user based on what type of 
> exception you caught.
>  
> Every one of my controller actions looks basically like this:
>  
> sub foo : Local {
>    eval {
>        ... do all the foo stuff, and throw exceptions where necessary
> };
> if ($@) {
>    my $err = $@;
>    if ($err->isa(MyApp::Exception::File) {
>        $msg = "Could not open that file";
>    }
>    elsif ($err->isa(MyApp::Exception::Number) {
>        ...       
>    }
>   ... etc.
> }
>  
> Of course there are other ways to return error values, and it's a 
> judgement call which way to choose -- but in places where you're 
> inclined to call "die", this works very nicely.
>  
> --phil
>
> Regards, Andreas
>
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
>
>
>

>
>
> --
> ==========================
> http://www.2people.org
>
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
>
>
>

>
>
> --
> Daniel McBrearty
> email : danielmcbrearty at gmail.com
> www.engoi.com : the multi - language vocab trainer
> BTW : 0873928131 _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3776 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060316/354cd295/attachment-0001.bin