[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [OSSTEST PATCH 6/9] db_retry: Suppress an "exiting via last" warning



Ian Campbell writes ("Re: [OSSTEST PATCH 6/9] db_retry: Suppress an "exiting 
via last" warning"):
> On Thu, 2015-12-17 at 18:38 +0000, Ian Jackson wrote:
> > Both of these are intentional.  Perl thinks they might not be.
> 
> ... and that's because it is a common enough mistake to think that next or
> last exits only the scope of the eval and therefore in this case to expect
> it to run "last if !length $@;", while it actually wont.

Yes.

> I would have expected that if you want to successfully exit (i.e. not die)
> the eval early and continue on with the remainder of the loop you should
> use return, and http://perldoc.perl.org/functions/eval.html seems to back
> that up ("the value returned is the value of the last expression evaluated
> inside the mini-program; a return statement may be also used,"), but
> earlier you said that return would generate the same warning, so I remain a
> bit confused.

Oh!  I was confused about the effect of `return' in an eval.  I
expected it to exit past the eval and return out of the calling
function.

> According to my reading of eval.html "return if $db_retry_stop eq 'abort'"
> would exit the eval with $@="" ("If there was no error, $@ is set to the
> empty string", it mentions last and goto bypassing this, but not return).
> Then since length "" is false that outer last would be run insteadand we
> are done with the loop as we wanted. AFAICT that would avoid the warning
> for the inner last, but is not usable for the inner next, and in any case
> using last inside the eval is actually more obvious in this instance, once
> one thinks one understands an eval (which in my case is still debatable I
> think)

I still think this reasoning about `return' is more fiddly than just
saying `last' or `next' when we mean `last' or `next'...

Particularly given that, now, there is a `no warnings qw(exiting)' to
cue the reader that they may need to check the FM.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.