Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBIx-Connector CPAN distribution.

Report information
The Basics
Id:
65196
Status:
resolved
Priority:
Low/Low

People
Owner:
dwheeler [...] cpan.org
Requestors:
nomad [...] null.net
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
0.51



Subject: Try::Tiny catch is not catching exceptions
Date: Fri, 28 Jan 2011 09:38:57 +1300
To: bug-DBIx-Connector@rt.cpan.org
From: Mark Lawrence <nomad@null.net>
According to the docs/SYNOPSIS the following should work: use DBIx::Connector; use Try::Tiny qw/ catch /; my $conn = DBIx::Connector->new( 'dbi:SQLite:dbname=junkxxx' ); $conn->txn(no_ping => sub { die 'WTF!'; }, catch { warn "Caught $_"; }) Unfortunately I get: WTF! at - line 7. Replacing s/catch/sub/ does the expected thing. I don't know if the docs or the code are broken... but here is a start on a test: diff --git a/t/txn.t b/t/txn.t index dd9a23a..f8210d7 100644 --- a/t/txn.t +++ b/t/txn.t @@ -5,6 +5,7 @@ use warnings; use Test::More tests => 104; #use Test::More 'no_plan'; use Test::MockModule; +use Try::Tiny; my $CLASS; BEGIN { @@ -159,6 +160,15 @@ ok $conn->txn(sub { }), 'Catch and handle another exception'; is $@, 'foo', '$@ still should not be changed'; +# Check Try::Tiny 'catch' method +ok $conn->txn(sub { + die 'WTF!'; +}, catch { + like $_, qr/WTF!/, 'Should catch another exception'; + like shift, qr/WTF!/, 'catch arg should also be the new exception'; +}), 'Catch and handle another exception'; +is $@, 'foo', '$@ still should not be changed'; + eval { $conn->txn(sub { die 'WTF!' }, catch => sub { die 'OW!' }) }; ok my $e = $@, 'Should catch exception thrown by catch'; like $e, qr/OW!/, 'And it should be the expected exception'; Secondly, and I'm not sure if this is related or not but I'm seeing this kind of problem in the wild: $self->conn->run(no_ping => sub { die "lkjsdf"; }, sub { warn "Caught no_ping $_"; }); $self->conn->run(ping => sub { die "lkjsdf"; }, sub { warn "Caught ping $_"; }); $self->conn->run(fixup => sub { die "fdsalkj"; }, sub { warn "Caught fixup $_"; }); ... Caught no_ping lkjsdf at ../sql-db/lib/SQL/DB.pm line 190. Caught ping lkjsdf at ../sql-db/lib/SQL/DB.pm line 196. fdsalkj at ../sql-db/lib/SQL/DB.pm line 202. Haven't managed to reproduce standalone yet. It seems that fixup mode is not running any kind of catch block if the main subroutine raises an exception, whereas ping and no_ping modes do. $DBIx::Connector::VERSION is 0.42. Mark. -- Mark Lawrence
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Thu, 27 Jan 2011 12:52:20 -0800
To: bug-DBIx-Connector@rt.cpan.org
From: "David E. Wheeler" <dwheeler@cpan.org>
Yeah, I got your email, it's on my list. I think the first bit is because Try::Tiny changed how catch works. So I'll probably remove that bit. More later. Best, David
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Mon, 31 Jan 2011 09:40:46 -0800
To: bug-DBIx-Connector@rt.cpan.org
From: "David E. Wheeler" <dwheeler@cpan.org>
On Jan 27, 2011, at 12:39 PM, Mark Lawrence via RT wrote:
Show quoted text
> WTF! at - line 7. > > Replacing s/catch/sub/ does the expected thing. I don't know if the > docs or the code are broken... but here is a start on a test:
Try::Tiny changed. I'm following up with Yuval to see if there's some way to get that functionality back. If not, I'll remove that documentation. In the meantime, you can use "catch" as an optional keyword for the sub, like so: $conn->txn(no_ping => sub { die 'WTF!'; }, catch => sub { warn "Caught $_"; }) Only slightly more annoying.
Show quoted text
> Secondly, and I'm not sure if this is related or not but I'm seeing > this kind of problem in the wild: > > $self->conn->run(no_ping => sub { > die "lkjsdf"; > }, sub { > warn "Caught no_ping $_"; > }); > > $self->conn->run(ping => sub { > die "lkjsdf"; > }, sub { > warn "Caught ping $_"; > }); > > $self->conn->run(fixup => sub { > die "fdsalkj"; > }, sub { > warn "Caught fixup $_"; > }); > > ... > > Caught no_ping lkjsdf at ../sql-db/lib/SQL/DB.pm line 190. > Caught ping lkjsdf at ../sql-db/lib/SQL/DB.pm line 196. > fdsalkj at ../sql-db/lib/SQL/DB.pm line 202.
Huh. Do you have RaiseError enabled?
Show quoted text
> Haven't managed to reproduce standalone yet. It seems that fixup mode > is not running any kind of catch block if the main subroutine raises an > exception, whereas ping and no_ping modes do. > > $DBIx::Connector::VERSION is 0.42.
The code does eval and handle exceptions; see the _fixup_run() method. Are you getting this only with run(), or with txn(), too? I haven't seen it; if you can figure out the pattern, a test case would help a lot. Thanks, David
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Thu, 17 Mar 2011 10:36:30 +1300
To: David Wheeler via RT <bug-DBIx-Connector@rt.cpan.org>
From: Mark Lawrence <nomad@null.net>
On Mon Jan 31, 2011 at 12:41:00PM -0500, David Wheeler via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65196 > > > On Jan 27, 2011, at 12:39 PM, Mark Lawrence via RT wrote: >
> > WTF! at - line 7. > > > > Replacing s/catch/sub/ does the expected thing. I don't know if the > > docs or the code are broken... but here is a start on a test:
> > Try::Tiny changed. I'm following up with Yuval to see if there's some > way to get that functionality back. If not, I'll remove that > documentation. > > In the meantime, you can use "catch" as an optional keyword for the > sub, like so: > > $conn->txn(no_ping => sub { die 'WTF!'; }, catch => sub { warn > "Caught $_"; }) > > Only slightly more annoying.
$conn->txn( no_ping => sub { die 'WTF!'; }, catch => sub { warn "Caught $_"; }, ); # Or more often because subs are large $conn->txn( no_ping => sub { die 'WTF!'; }, catch => sub { warn "Caught $_"; } ); So after using "catch => sub" a few times with nice indentation the annoyance has gone away, and the readability is still quite good. If not better. In fact, now that I've been using this I notice that it is more consistent when both subroutines are specified as "sub {...}" instead of one of them being a special keyword. I would not miss the Try::Tiny integration if you decided to remove that feature. What is nice though about Try::Tiny (since I don't wanting to throw the bathwater out completely) is when you can use it fully: The "try {} catch {}" grouping looks great, and is *almost* duplicated in DBIx::Connector. So what do you think about the following syntax? $conn->txn( try => sub { die 'WTF!'; }, catch => sub { warn "Caught $_"; } ); Most of the time my interest in the code is about *my* actions, not what DBIx::Connector is going to do under the hood when things fail. I generally set $conn->mode and forget about it, and the above syntax I think puts the focus in the right place. To extend the above idea further one could use "try_fixup", "try_no_ping" etc for the one-off change to the mode. The good news is that these could be added without affecting the current syntax.
Show quoted text
> > Secondly, and I'm not sure if this is related or not but I'm seeing > > this kind of problem in the wild: > > > > $self->conn->run(no_ping => sub { die "lkjsdf"; }, sub { warn > > "Caught no_ping $_"; }); > > > > $self->conn->run(ping => sub { die "lkjsdf"; }, sub { warn > > "Caught ping $_"; }); > > > > $self->conn->run(fixup => sub { die "fdsalkj"; }, sub { warn > > "Caught fixup $_"; }); > > > > ... > > > > Caught no_ping lkjsdf at ../sql-db/lib/SQL/DB.pm line 190. > > Caught ping lkjsdf at ../sql-db/lib/SQL/DB.pm line 196. fdsalkj > > at ../sql-db/lib/SQL/DB.pm line 202.
> > Huh. Do you have RaiseError enabled?
Yes. But see below.
Show quoted text
>
> > Haven't managed to reproduce standalone yet. It seems that fixup > > mode is not running any kind of catch block if the main subroutine > > raises an exception, whereas ping and no_ping modes do. > > > > $DBIx::Connector::VERSION is 0.42.
> > The code does eval and handle exceptions; see the _fixup_run() > method. Are you getting this only with run(), or with txn(), too? > > I haven't seen it; if you can figure out the pattern, a test case > would help a lot.
I couldn't narrow the problem down and now it has gone away - not on it's own of course, I've been doing lots of re-factoring of the calling code. I'm going to write it off as something on my side. Cheers, Mark. -- Mark Lawrence
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Thu, 17 Mar 2011 11:55:32 -0700
To: bug-DBIx-Connector@rt.cpan.org
From: "David E. Wheeler" <david@kineticode.com>
On Mar 16, 2011, at 2:36 PM, Mark Lawrence via RT wrote:
Show quoted text
>> Try::Tiny changed. I'm following up with Yuval to see if there's some >> way to get that functionality back. If not, I'll remove that >> documentation. >> >> In the meantime, you can use "catch" as an optional keyword for the >> sub, like so: >> >> $conn->txn(no_ping => sub { die 'WTF!'; }, catch => sub { warn >> "Caught $_"; }) >> >> Only slightly more annoying.
I forgot about this ticket. There might be a way to fix Try::Tiny, but I think I'm more inclined to just remove the documentation of it, since there's nothing specific to Try::Tiny in the DBIx::Connector code.
Show quoted text
> So after using "catch => sub" a few times with nice indentation the > annoyance has gone away, and the readability is still quite good. If > not better. In fact, now that I've been using this I notice that it is > more consistent when both subroutines are specified as "sub {...}" > instead of one of them being a special keyword. I would not miss the > Try::Tiny integration if you decided to remove that feature.
Cool.
Show quoted text
> What is nice though about Try::Tiny (since I don't wanting to throw the > bathwater out completely) is when you can use it fully: The "try {} > catch {}" grouping looks great, and is *almost* duplicated in > DBIx::Connector. So what do you think about the following syntax? > > $conn->txn( > try => sub { > die 'WTF!'; > }, > catch => sub { > warn "Caught $_"; > } > );
Huh. Yeah, I like that.
Show quoted text
> Most of the time my interest in the code is about *my* actions, not > what DBIx::Connector is going to do under the hood when things fail. I > generally set $conn->mode and forget about it, and the above syntax > I think puts the focus in the right place. > > To extend the above idea further one could use "try_fixup", "try_no_ping" > etc for the one-off change to the mode. The good news is that these > could be added without affecting the current syntax.
What about: $conn->txn( try => fixup => sub { die 'WTF!'; }, catch => sub { warn "Caught $_"; } ); ? No, wait. That would imply: $conn->txn( try => fixup => sub { die 'WTF!'; } ); Which isn't true. The try can't be a no-op. So I think I'll just leave it as-is. Use `run` or `fixup` or `no_ping` for balance: $conn->txn( fixup => sub { die 'WTF!'; }, catch => sub { warn "Caught $_"; } ); I think that looks best, actually. Just be explicit which mode you're using.
Show quoted text
> I couldn't narrow the problem down and now it has gone away - not on > it's own of course, I've been doing lots of re-factoring of the calling > code. I'm going to write it off as something on my side.
Okay, great, thanks! David
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Sun, 27 Mar 2011 15:56:16 +1300
To: David Wheeler via RT <bug-DBIx-Connector@rt.cpan.org>
From: Mark Lawrence <nomad@null.net>
On Thu Mar 17, 2011 at 02:55:45PM -0400, David Wheeler via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65196 > >
> > What is nice though about Try::Tiny (since I don't wanting to throw the > > bathwater out completely) is when you can use it fully: The "try {} > > catch {}" grouping looks great, and is *almost* duplicated in > > DBIx::Connector. So what do you think about the following syntax? > > > > $conn->txn( > > try => sub { > > die 'WTF!'; > > }, > > catch => sub { > > warn "Caught $_"; > > } > > );
> > Huh. Yeah, I like that.
But I didn't give strong enough reasoning for you to add it...
Show quoted text
> Which isn't true. The try can't be a no-op. So I think I'll just
Although you were referring to your examples, the 'meaning' behind 'try' in mine above is not a no-op. It actually would stand for "use the current default mode when 'trying'".
Show quoted text
> leave it as-is. Use `run` or `fixup` or `no_ping` for balance: > > $conn->txn( > fixup => sub { > die 'WTF!'; > }, > catch => sub { > warn "Caught $_"; > } > ); > > I think that looks best, actually. Just be explicit which mode you're > using.
It does look best when balanced but being explicit is the only way of doing so. If you want to default to the current mode (which lets you make a global change without changing all your code) you stay unbalanced. I've never quite liked interfaces that took an even and odd number of arguments... but it's your bikeshed :-) Mark. -- Mark Lawrence
On Sat Mar 26 22:56:36 2011, nomad@null.net wrote:
Show quoted text
> Although you were referring to your examples, the 'meaning' behind > 'try' in mine above is not a no-op. It actually would stand for "use > the current default mode when 'trying'".
Yeah, but the term `try` actually implies that it will catch an exception, right? And then, if there is no catch, it will silently succeed. Or such is the case with `eval` at any rate. What happens in most languages when you `try` code that dies and don't `catch`? Does it die or just swallow the error and move on? Will have to look into that. If people expect `try` never to swallow the exception, then I can add it as a no-op (meaning "the default mode"). If they do expect it to swallow the exception, then it would be a bit more complicated. And more error- prone, IMHO.
Show quoted text
> It does look best when balanced but being explicit is the only way of > doing so. If you want to default to the current mode (which lets you > make a global change without changing all your code) you stay > unbalanced. I've never quite liked interfaces that took an even and odd > number of arguments... but it's your bikeshed :-)
Yeah, I agree it looks better balanced. David
On Tue May 10 12:12:52 2011, DWHEELER wrote:
Show quoted text
> Yeah, but the term `try` actually implies that it will catch an > exception, right? And then, if > there is no catch, it will silently succeed. Or such is the case with > `eval` at any rate. What > happens in most languages when you `try` code that dies and don't > `catch`? Does it die or > just swallow the error and move on? Will have to look into that. If > people expect `try` never to > swallow the exception, then I can add it as a no-op (meaning "the > default mode"). If they do > expect it to swallow the exception, then it would be a bit more > complicated. And more error- > prone, IMHO.
Nevertheless, looking at Try::Tiny, that does seem to be the expectation. Its docs say: # just silence errors try { die "foo"; }; Looking at the code, I think I could actually make that happen pretty easily. However, it would then also imply that you should be able to do `try => fixup`, because `fixup` does not imply `try`. And I think that syntax looks awful. So I see a few possible solutions: 1. Use some term other than `try` to mean "the default mode". Suggestions welcome (not `default`; ew). 2. Use `try`, make it swallow exceptions if there's no `catch`, and modify the other params to imply `try`. I don't think this is a good idea for compatibility reasons. 3. Use `try`, make it swallow exceptions if there's no `catch`, and add `try_fixup`, `try_ping`, and `try_no_ping`. Not really keen on those parameters, though. The trouble is that the use of `catch` has *implied* `try`, which probably wasn't the best idea. Hell, adding `catch` at all probably wasn't the greatest idea; one should probably just use Try::Tiny and not bother with it in DBIx::Connector (should never have been DBIC's domain). Anyway, just some thoughts. I'll think about it some more and make a decision soonish. David
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Thu, 12 May 2011 12:17:36 +1200
To: David Wheeler via RT <bug-DBIx-Connector@rt.cpan.org>
From: Mark Lawrence <nomad@null.net>
Wow, lots of thoughts, both here and on your blog. I'm somewhat sorry for opening up this can of worms. On Tue May 10, 2011 at 12:23:16PM -0400, David Wheeler via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65196 > > > > So I see a few possible solutions: > > 1. Use some term other than `try` to mean "the default mode". > Suggestions welcome (not `default`; ew). > > 2. Use `try`, make it swallow exceptions if there's no `catch`, and > modify the other params to imply `try`. I don't think this is a good > idea for compatibility reasons. > > 3. Use `try`, make it swallow exceptions if there's no `catch`, and > add `try_fixup`, `try_ping`, and `try_no_ping`. Not really keen on > those parameters, though.
( plus your 3. from the blog: depreciate try/catch altogether )
Show quoted text
> > The trouble is that the use of `catch` has *implied* `try`, which > probably wasn't the best idea. Hell, adding `catch` at all probably > wasn't the greatest idea; one should probably just use Try::Tiny and > not bother with it in DBIx::Connector (should never have been DBIC's > domain).
I must admit I'm starting to lose track of all the different possible contexts in which the try/fixup/ping/noping/catch keywords apply. I think this is partly due to the mixing of several types of exceptions, and how they can be handled. For my own benefit (I know you already know this) I'll re-word the problem: We have Standard Perl Exceptions: Can be raised in user code, or by DBI/DBD (assuming RaiseError) at any time. Before DBIx::Connector the calling code has to handle this on their own with explicit calls to begin_work, commit and rollback. Either with "eval/if $@" or Try::Tiny try/catch: try { begin_work <work> commit } catch { rollback <handler> } Messy to write and messy to try and find out if the error was generated by SQL, Perl, or network/connection, so (most?) people treat all errors the same way? DBIx::Connector adds two nice things relevant to this discussion: - Encapsulates the begin_work/commit/rollback/code into a single method call - An internal catch/retry handler for connection-failures In my opinion these are the main reasons for using DBIx::Connector. Both of these features involve a form of exception handling. The questions I see in front of me are: 1. Whether to integrate user exception-handlers into the DBIx::Connector method calls; 2. If the answer to the above question is yes, then how to integrate the user-handler code with existing connection-failure mode keywords. Ok, now I've re-written what you've already said and not really moved anything forwards. But at least I can think more clearly :-/ Here are my thoughts on your blog post options: 1. "default" keyword doesn't give me a warm feeling and I can't think of anything better. 2. I sort of like the "try" keyword (I should since I suggested it :-) and I don't find the try_fixup thing very ugly, but I also never use the per-statement mode keywords. I agree about the behaviour change not being ideal. 3. I don't like the idea of going back to exception handling outside of the run/txn/svp calls. If DBIx::Connector is going to call rollback for me I want to let it call my handler as well. In other words either make everything explicit, or make everything implicit. Here is a fourth suggestion. Depreciate the 'catch' keyword in the existing run/txn/svp calls (or let it keep its current behaviour) and introduce new *methods* that make the handling explicit: Keep current behaviour with no (or external) user-handlers: $conn->run(sub{ # can die and user program stops, but will re-run/fixup # depending on the default mode }); try { $conn->txn(no_ping => sub{ # can die and user program stops, will not ping because # explicitly set }); } catch { # do our own thing } # etc etc Add new behaviour: # never dies (swallows exceptions) but retries according to default # mode $conn->try_txn(sub{ # stuff which can die }); $conn->try_txn(ping => sub{ # stuff which can die }, catch => sub { # handle the non-connection exceptions }); $conn->try_svp(fixup => sub{ # as above }, catch => sub { # as above }); The above variations make things explicit where they need to be, follow the same pattern as try/eval, and keep existing compatibility. I was going to say I much prefer not having the extra indentation without external try/eval but I'm now thinking asthetics should come waaay after any others discussions have finished, so that's not really an argument. Likewise the importantance to me of "balance" has diminished since we last spoke about that issue. Hope this helps. Mark. -- Mark Lawrence
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Thu, 12 May 2011 12:33:18 +1200
To: David Wheeler via RT <bug-DBIx-Connector@rt.cpan.org>
From: Mark Lawrence <nomad@null.net>
On Tue May 10, 2011 at 12:23:16PM -0400, David Wheeler via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65196 > > > Looking at the code, I think I could actually make that happen pretty > easily. However, it would then also imply that you should be able to > do `try => fixup`, because `fixup` does not imply `try`. And I think > that syntax looks awful.
To be honest, I've never really gone for the explicit mode setting in the run/txn/svp calls. I have always until now just "set and forget" the default mode. I think needing to change it is a rare enough occurance that (re)setting the default around a methods is acceptable. Perhaps your experience is different, you must have had a reason for including them. I find the *external* (user) handling of exceptions to be more important. If I was starting from scratch I think I would go for this: $conn->txn( try => sub { # work }, catch => sub { # handler } ); Hmmm... I have just specified something with *more* depth (in the handler) than an external exception handling scenario: try => sub { $conn->txn( # work ); } catch => sub { # handler }; However this Try::Tiny combination somewhat hides the fact that $conn is still doing some exception handling of its own, resulting in a rollback at some point. Ok, in the end I actually prefer my $conn->try_txn(..) suggestion from the previous mail. Sorry for the thinking out loud. Mark. -- Mark Lawrence
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Wed, 11 May 2011 19:39:39 -0700
To: bug-DBIx-Connector@rt.cpan.org
From: "David E. Wheeler" <dwheeler@cpan.org>
On May 11, 2011, at 5:33 PM, Mark Lawrence via RT wrote:
Show quoted text
> However this Try::Tiny combination somewhat hides the fact that $conn > is still doing some exception handling of its own, resulting in a > rollback at some point.
Yes, but you don't actually need to know that or even be concerned with it. You happen to know that because you used to write the code the old way, not because there's anything about the API to suggest it.
Show quoted text
> Ok, in the end I actually prefer my > $conn->try_txn(..) suggestion from the previous mail. Sorry for the > thinking out loud.
No worries. I've talked to a bunch of people about this, and so far, with one exception, their advice has been to go with #3 from my blog post: rip out the exception handling. So I think that's what I'll do. I'm thinking: 1. Remove all documentation of it, except for one spot that says it's deprecated, and release that change. 2. A month later, release a new version that warns when a catch block is passed. I'd set it up to only warn once for each caller so that logs don't fill up. 3. A month after, that, release a new version with the catch stuff completely removed. Would that be sufficient for you? I have code that needs to change, too… Best, David
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Thu, 12 May 2011 15:07:18 +1200
To: David Wheeler via RT <bug-DBIx-Connector@rt.cpan.org>
From: Mark Lawrence <nomad@null.net>
On Wed May 11, 2011 at 10:39:49PM -0400, David Wheeler via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65196 > > > On May 11, 2011, at 5:33 PM, Mark Lawrence via RT wrote: >
> > However this Try::Tiny combination somewhat hides the fact that > > $conn is still doing some exception handling of its own, resulting > > in a rollback at some point.
> > Yes, but you don't actually need to know that or even be concerned > with it. You happen to know that because you used to write the code > the old way, not because there's anything about the API to suggest > it.
Right.
Show quoted text
> No worries. I've talked to a bunch of people about this, and so far, > with one exception, their advice has been to go with #3 from my blog > post: rip out the exception handling.
Do one thing, and do it well. Can't disagree with that in principle, or practically in this case.
Show quoted text
> So I think that's what I'll do. I'm thinking: > > 1. Remove all documentation of it, except for one spot that says it's > deprecated, and release that change. > > 2. A month later, release a new version that warns when a catch block > is passed. I'd set it up to only warn once for each caller so that > logs don't fill up. > > 3. A month after, that, release a new version with the catch stuff > completely removed. > > Would that be sufficient for you?
Sure. I have a quick turn-around cycle on my stuff. This schedule is fine. Thanks for the cleaning up. Sorry to have generated so much work. Mark. -- Mark Lawrence
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Wed, 11 May 2011 20:08:27 -0700
To: bug-DBIx-Connector@rt.cpan.org
From: "David E. Wheeler" <dwheeler@cpan.org>
On May 11, 2011, at 8:07 PM, Mark Lawrence via RT wrote:
Show quoted text
>> Would that be sufficient for you?
> > Sure. I have a quick turn-around cycle on my stuff. This schedule is > fine. > > Thanks for the cleaning up. Sorry to have generated so much work.
Thanks. Shit happens, you know? Best, David
So the exception-handling stuff has been removed from Try::Tiny, and it now recommends that one do one's own exception-handling with Try::Tiny. Give 0.51 a try. I think that resolves this ticket, yeah?
Subject: Re: [rt.cpan.org #65196] Try::Tiny catch is not catching exceptions
Date: Fri, 16 Mar 2012 15:37:05 +1300
To: David Wheeler via RT <bug-DBIx-Connector@rt.cpan.org>
From: Mark Lawrence <nomad@null.net>
On Thu Mar 15, 2012 at 04:54:10PM -0400, David Wheeler via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65196 > > > So the exception-handling stuff has been removed from Try::Tiny, and
I assume you mean removed from DBIx::Connector?
Show quoted text
> it now recommends that one do one's own exception-handling with > Try::Tiny. Give 0.51 a try. I think that resolves this ticket, yeah?
Happy to see it closed. Mark. -- Mark Lawrence
Please do not reply (it re-opens the ticket!).


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.