From: Avdi Grimm <avdi@...>
Date: 2014-11-12T09:31:25-05:00
Subject: [ruby-core:66226] Re: [ruby-trunk - Feature #10042] Deprecate postfix rescue syntax for removal in 3.0

--001a113de58653fcdf0507aa41ba
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 10, 2014 at 10:25 PM, <matz@ruby-lang.org> wrote:

> I haven't seen any "serious" problem caused by exceptions swallowed by
> postfix "rescue". So I don't worry too much about the issue.


I won't claim that writing a book on Ruby exceptions makes me an expert.
But at least I've made a special study of them for the past decade or so of
Ruby use, and over numerous large-scale client projects. Of bugs that could
be traced to use of a language feature, postfix rescue is easily in the top
three. In fact, offhand I'm not sure I can think of *any* language feature
whose use has led directly to more problems than this one. Unless you count
"the existence of nil" as a language feature ;-)

Postfix rescue bugs are especially insidious, because they usually hide
*other* bugs.

Can you accidentally throw away exceptions without it? Sure. But other
methods are more visually obvious. Postfix rescue hides out at the ends of
long lines in legacy codebases, quietly breaking things.

The abuse of postfix rescue is so bad in Ruby projects that at this point I
consider only one usage of it acceptable: `rescue $!` for converting
exceptions to returns. I flag any other usage as an error, because if it
isn't causing problems already, it almost certainly will eventually.

I would like to see some equivalent of `rescue $!` stay in the language,
but other than that I'd be more than happy to see it leave the building
entirely.

--
Avdi Grimm
http://avdi.org

--001a113de58653fcdf0507aa41ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Nov 10, 2014 at 10:25 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:=
matz@ruby-lang.org" target=3D"_blank">matz@ruby-lang.org</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">I haven&#39;t seen any &quot;serious&=
quot; problem caused by exceptions swallowed by postfix &quot;rescue&quot;.=
 So I don&#39;t worry too much about the issue.</blockquote></div><br>I won=
&#39;t claim that writing a book on Ruby exceptions makes me an expert. But=
 at least I&#39;ve made a special study of them for the past decade or so o=
f Ruby use, and over numerous large-scale client projects. Of bugs that cou=
ld be traced to use of a language feature, postfix rescue is easily in the =
top three. In fact, offhand I&#39;m not sure I can think of *any* language =
feature whose use has led directly to more problems than this one. Unless y=
ou count &quot;the existence of nil&quot; as a language feature ;-)</div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Postfix rescu=
e bugs are especially insidious, because they usually hide *other* bugs.</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Can you =
accidentally throw away exceptions without it? Sure. But other methods are =
more visually obvious. Postfix rescue hides out at the ends of long lines i=
n legacy codebases, quietly breaking things.</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">The abuse of postfix rescue is so ba=
d in Ruby projects that at this point I consider only one usage of it accep=
table: `rescue $!` for converting exceptions to returns. I flag any other u=
sage as an error, because if it isn&#39;t causing problems already, it almo=
st certainly will eventually.</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">I would like to see some equivalent of `rescue $!` =
stay in the language, but other than that I&#39;d be more than happy to see=
 it leave the building entirely.<br><br clear=3D"all"><div><div class=3D"gm=
ail_signature"><div dir=3D"ltr"><div>--</div>Avdi Grimm<br><a href=3D"http:=
//avdi.org" target=3D"_blank">http://avdi.org</a><br><br></div></div></div>
</div></div>

--001a113de58653fcdf0507aa41ba--