Issue #10042 has been updated by Avdi Grimm.


 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

----------------------------------------
Feature #10042: Deprecate postfix rescue syntax for removal in 3.0
https://bugs.ruby-lang.org/issues/10042#change-49914

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: Next Major
----------------------------------------
The postfix rescue notation is convenient...but almost always is a really bad antipattern.

An example of the notation:

    Integer(f) rescue f # returns f if it is not parseable as an Integer

It silently ignores all StandardError raised by a piece of code...which often covers *many* more exceptions than the user *wants* to be ignoring.

It also hides the cost of constructing and throwing away all those ignored exceptions.

I believe Matz has even said in the past that he regrets adding the feature.

In any case, I propose that "rescue nil" should be deprecated with a warning (either always on or only when verbose) and we should plan to remove it in 3.0.

Who's with me?!



-- 
https://bugs.ruby-lang.org/