Forum: Ruby Using "rescue" inline

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0f1f17ba297242e9d3c86d4cc0a6ea85?d=identicon&s=25 Iñaki Baz Castillo (Guest)
on 2009-02-25 18:13
(Received via mailing list)
Hi, is it correct the following "rescue" usage?

myvar = 1  # Fixnum
othervar = myvar.downcase rescue myvar
=> 1

It seems to work, but is it really correct? Thanks.
8666d1ebabcea440585dfe831a4af9f1?d=identicon&s=25 Brian Adkins (Guest)
on 2009-02-25 19:03
(Received via mailing list)
Iñaki Baz Castillo <ibc@aliax.net> writes:

> Hi, is it correct the following "rescue" usage?
>
> myvar = 1  # Fixnum
> othervar = myvar.downcase rescue myvar
> => 1
>
> It seems to work, but is it really correct? Thanks.

Naturally, "correctness" depends on what you're trying to
accomplish. That is one valid use of rescue as a statement modifier
which will assign the value of myvar.downcase to othervar unless the
downcase method raises an exception, in which case it will assign
myvar instead. You can also use more than one rescue as in:

x = foo(y) rescue bar(y) rescue baz(y) rescue nil
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-02-25 19:06
Iñaki Baz Castillo wrote:
> Hi, is it correct the following "rescue" usage?
>
> myvar = 1  # Fixnum
> othervar = myvar.downcase rescue myvar
> => 1
>
> It seems to work, but is it really correct? Thanks.

Yes. What you have written is shorthand form of rescue, equivalent to:

myvar = 1
othervar = begin
  myvar.downcase
rescue StandardError
  myvar
end
Ef3aa7f7e577ea8cd620462724ddf73b?d=identicon&s=25 Rob Biedenharn (Guest)
on 2009-02-25 19:09
(Received via mailing list)
On Feb 25, 2009, at 12:11 PM, Iñaki Baz Castillo wrote:

> <ibc@aliax.net>
Hmm, "correct"? Well, it is certainly legal syntax and is equivalent to:

othervar = begin
              myvar.downcase
            rescue
              myvar
            end

But, it might not be the best way to shave the yak.

othervar = myvar.respond_to?(:downcase) ? myvar.downcase : myvar

might perform better if the exception to be rescued is expensive to
construct only to then be thrown away.  (I don't know if there's any
special optimization of the expression form of rescue compared to the
block form.)

It also can hide problems that you won't know that you have. For
example,
   myvar = nil
   othervar = myvar.downcase rescue myvar
Did you want to set othervar to nil also?
Perhaps you need othervar as a downcased String? Maybe it would be
better as:
   othervar = myvar.to_s.downcase

In any case, you'd have to decide.

-Rob


Rob Biedenharn    http://agileconsultingllc.com
Rob@AgileConsultingLLC.com
914e20950aa773fd66e4525fc9192309?d=identicon&s=25 Herman Martinelli (Guest)
on 2009-02-25 19:54
(Received via mailing list)
Brian Adkins wrote:
> Naturally, "correctness" depends on what you're trying to
> accomplish.

LOL
That's really a good one (in addition to the valuable Ruby answer).

H.
0f1f17ba297242e9d3c86d4cc0a6ea85?d=identicon&s=25 Iñaki Baz Castillo (Guest)
on 2009-02-25 20:59
(Received via mailing list)
El Miércoles, 25 de Febrero de 2009, Rob Biedenharn
escribió:
> othervar = myvar.respond_to?(:downcase) ? myvar.downcase : myvar
>
> might perform better if the exception to be rescued is expensive to
> construct only to then be thrown away.  (I don't know if there's any
> special optimization of the expression form of rescue compared to the
> block form.)

Really good point. But I've done some benchmarks comparing both
approache and
using "rescue" is ~ 0.30e-5 faster than your approach (even if yours
seems
more ellegant to me).


> It also can hide problems that you won't know that you have. For
> example,
>    myvar = nil
>    othervar = myvar.downcase rescue myvar
> Did you want to set othervar to nil also?

Not exactly, but myvar could be a Fixnum so othervar would also be a
Fixnum.
But if myvar is a String then I want othervar to be the same String but
downcase.


Thanks a lot.
Ef3aa7f7e577ea8cd620462724ddf73b?d=identicon&s=25 Rob Biedenharn (Guest)
on 2009-02-25 21:41
(Received via mailing list)
On Feb 25, 2009, at 2:54 PM, Iñaki Baz Castillo wrote:

> using "rescue" is ~ 0.30e-5 faster than your approach (even if yours
> seems
> more ellegant to me).

It depends on how often myvar.downcase raises an exception. If that's
really an exceptional occurrence, then just rescuing the occasional
failure is the Ruby way.

> downcase.
>
>
> Thanks a lot.
> --
> Iñaki Baz Castillo


de nada

-Rob

Rob Biedenharn    http://agileconsultingllc.com
Rob@AgileConsultingLLC.com
E16e84e861c1815ce11ba7bd851c857d?d=identicon&s=25 lasitha (Guest)
on 2009-02-26 12:27
(Received via mailing list)
On Thu, Feb 26, 2009 at 1:24 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> It also can hide problems that you won't know that you have. For
>> example,
>>    myvar = nil
>>    othervar = myvar.downcase rescue myvar
>> Did you want to set othervar to nil also?
>
> Not exactly, but myvar could be a Fixnum so othervar would also be a Fixnum.
> But if myvar is a String then I want othervar to be the same String but
> downcase.

This may be stating the obvious but code that branches based on type
is smelly.  That is not to say it's always wrong, just always at least
a little smelly :).  Particularly if you find multiple places in the
code having to deal with Fixnum and String conditionally.

The inline rescue slightly obscures the conditional but the smell
remains.  It may be worthwhile reconsidering whether you really want
myvar to hold disparate types.

I would also reiterate Rob's concern that this rescue could easily
hide some unrelated bug (mvay being nil being the most obvious).

These two concerns would be enough for me to reconsider, but as usual,
it all depends on context.

Cheers,
lasitha
0f1f17ba297242e9d3c86d4cc0a6ea85?d=identicon&s=25 Iñaki Baz Castillo (Guest)
on 2009-02-26 15:31
(Received via mailing list)
2009/2/26 lasitha <lasitha.ranatunga@gmail.com>:
>
> hide some unrelated bug (mvay being nil being the most obvious).
>
> These two concerns would be enough for me to reconsider, but as usual,
> it all depends on context.

Yes, you are right, I'll consider it. Thanks a lot.
This topic is locked and can not be replied to.