Issue #10042 has been updated by Yukihiro Matsumoto.

Assignee set to Yukihiro Matsumoto
Target version changed from next minor to Next Major

Hedius, separate your concern, performance and language design.

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

Of course specifying exception class reduce chance for misbehavior, so if some one come up with nice idea, I'd love to merge and encourage it. But adding new reserved word is unacceptable. Any idea?

I don't care much about the performance here. Adding new syntax won't solve the issue.
We can just discourage use of exceptions in tight loops in the documentations.

Matz.


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

* 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/