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.
Iñaki Baz C. (Guest)
on 2009-02-25 19: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.
Brian A. (Guest)
on 2009-02-25 20:03
(Received via mailing list)
Iñaki Baz C. <removed_email_address@domain.invalid> 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
Brian C. (Guest)
on 2009-02-25 20:06
Iñaki Baz C. 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
Rob B. (Guest)
on 2009-02-25 20:09
(Received via mailing list)
On Feb 25, 2009, at 12:11 PM, Iñaki Baz C. wrote:

> <removed_email_address@domain.invalid>
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 B.    http://agileconsultingllc.com
removed_email_address@domain.invalid
Herman M. (Guest)
on 2009-02-25 20:54
(Received via mailing list)
Brian A. 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.
Iñaki Baz C. (Guest)
on 2009-02-25 21:59
(Received via mailing list)
El Miércoles, 25 de Febrero de 2009, Rob B.
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.
Rob B. (Guest)
on 2009-02-25 22:41
(Received via mailing list)
On Feb 25, 2009, at 2:54 PM, Iñaki Baz C. 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 C.


de nada

-Rob

Rob B.    http://agileconsultingllc.com
removed_email_address@domain.invalid
lasitha (Guest)
on 2009-02-26 13:27
(Received via mailing list)
On Thu, Feb 26, 2009 at 1:24 AM, Iñaki Baz C. 
<removed_email_address@domain.invalid> 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
Iñaki Baz C. (Guest)
on 2009-02-26 16:31
(Received via mailing list)
2009/2/26 lasitha <removed_email_address@domain.invalid>:
>
> 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.