Skip Menu |

This queue is for tickets about the Try-Tiny CPAN distribution.

Report information
The Basics
Id: 54250
Status: rejected
Priority: 0/
Queue: Try-Tiny

People
Owner: Nobody in particular
Requestors: bohica [...] ntlworld.com
Cc: ribasushi [...] leporine.io
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: 0.04



Subject: It would be really handy to have the try return value in finally
I notice finally has been added and thought great, this will be a good for my test code but I don't know what try will return in the finally block. Consider: use Test::More; try { die "fred\n" if $something; 1; } catch { diag("died with $_"); 0; } finally { # some cleanup code # following does not work as finally does not know what try will return ok($_[0], "test ok"); }; so now I have to do: my $x = try { die "fred\n" if $something; 1; } catch { diag("died with $_"); 0; } finally { # some cleanup code }; ok($x, "test ok"); Does not make a massive difference but it would be really neat to know in finally what try was going to return. I imagine it must be known by then. Martin -- Martin J. Evans Wetherby, UK
From: felix.ostmann [...] thewar.de
Perhaps a better solution would be: try {} catch {} finally {} success {} And success will be called with the return value from try! No changes to the other blocks. Perhaps another name will be better, but when i look at my code this extra will help at many situations! I can write a patch and send a pull request in github if this will be a good feature! OK?
From: felix.ostmann [...] thewar.de
I think the order was not right: finally is finally! try {} catch {} success {} finally {}
I've hit this problem, too, and have had to work around it. Here's an example from my code which checks a server's health. my $out; try { reload_config; reconnect_database; ... } catch { $out = "DEAD\n$_"; } finally { return if @_; $out = "OK\n"; $out .= report_on_config; }; return $out; A success block would make that a bit easier. my $out; try { reload_config; reconnect_database; ... } catch { $out = "DEAD\n$_"; } success { $out = "OK\n"; $out .= report_on_config; }; return $out;
This was made possible in 0.07 - @_ == 0 when the try block succeeded without errors (and contains the exception otherwise).
From: felix.ostmann [...] thewar.de
Am Mi 27. Apr 2011, 18:47:49, DOY schrieb: Show quoted text
> This was made possible in 0.07 - @_ == 0 when the try block succeeded > without errors (and contains the exception otherwise).
? That has nothing to do with this bug/wish? Other example from Catalyst: detach cannot be called within try {} (because it use errorhandling) NOT WORKING: try { my $url = $self->do_something(); $c->uri_for("/$url"); $c->detach; } catch { $_->rethrow if !$_->isa('Its::My::Fault'); ... } WORKING/WISH: try { $self->do_something(); } catch { $_->rethrow if !$_->isa('Its::My::Fault'); ... } success { $c->uri_for("/$_"); $c->detach; } VS my $url; try { $url = $self->do_something(); } catch { $_->rethrow if !$_->isa('Its::My::Fault'); ... } finally { return if @_ || !$url; $c->uri_for("/$url"); $c->detach; } VS my $url = try { $self->do_something(); } catch { $_->rethrow if !$_->isa('Its::My::Fault'); ... return; } if ($url) { $c->uri_for("/$url"); $c->detach; } The first syntax would be very clear! $_ and @_ should be set ($_ = $_[0])
From: felix.ostmann [...] thewar.de
Would you accept a patch for this? Otherwise please close this :-/
From: felix.ostmann [...] thewar.de
Thinking more about the problem gives another problem ... what will happen, if a success { } block throw another error. Will finally then never executed? Perhaps the order is only important. finally itself cannot die, so try -> catch -> finally -> success could be the solution. It is only important, that success can throw again (and dont handle it special). Am Di 18. Sep 2012, 05:24:45, Sadrak schrieb: Show quoted text
> Would you accept a patch for this? Otherwise please close this :-/
On Tue Sep 18 05:34:25 2012, Sadrak wrote: Show quoted text
> It is only important, that success can throw again (and dont handle it > special).
Before going further with this semantics, finally needs to be cleaned up (as it can not throw under the current implementation). See commit message of https://github.com/ribasushi/try-tiny/commit/5f5e92c0
I'd honestly rather not make the semantics of Try::Tiny any more complicated than they already are. It's true that due to issues in perl, try blocks can't work like they do in other languages, but adding on a lot of different workarounds to this problem isn't really going to help the situation. As for finally blocks not being able to throw exceptions, I see this as a feature, honestly. I think the warning that was added in 0.13 is sufficient.