On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> Catalyst does wrap the requests in eval, so if a controller dies you
> have to look for the exception stuffed int $c->errors somewhere
>
> If you don't mind doing a rollback on all requests then that sure
> makes things nice and simple.  Thanks.

The rollback seems to be pretty cheap when no changes have been made,
so I think it's a reasonable solution.  It's what Apache::DBI has done
for years.

> To avoid running code that you only want to happen if the transaction
> commits.  For example, sending an email.
>
> If you have one sub:
>
>     do_stuff_and_send_mail {
>
>         {
>             local $dbh->{AutoCommit} = 0;
>             $object->do_stuff;
>         } # commit (unless nested)
>
>         send_mail( "do_stuff happened!" );
>     }
>
> Obviously, the mail won't be sent if there's an exception.  But, if
> do_stuff_and_sent_mail() is called from code that's in a transaction
> (nested transaction) then send_mail can happen, and after the sub
> above returns an exception would roll back the entire transaction.
> But send_mail() still already sent the mail.

I think I'm starting to see the problem.  It's not nested transactions
that are an issue for you, it's nested exception handling.

In my system, the code above will never run send_mail() if there's an
exception.  It will throw the exception, nothing will catch it, and
I'll get a stack trace in my log (thanks to Carp) and a pretty error
page sent to the user (thanks to apache), and my cleanup handler will
do a rollback.  It sounds like you're thinking of a situation where
that block is really an eval, and after doing a rollback, you just
continue.  I simply don't do that.  I only catch exceptions when I
intend to try to correct them and continue the request, which is what
you're saying you want to avoid here.

One option for you is to re-throw the exception outside the eval block
(I like how easy Exception::Class makes that), but that does beg the
question of what the eval block was there for in the first place.  I
suspect it was there to make sure a rollback happens, which a cleanup
handler already takes care of.

- Perrin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Rose-db-object mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/rose-db-object

Reply via email to