[#41916] Proposal: Bitmap Marking GC — Narihiro Nakamura <authornari@...>

Hi.

18 messages 2012/01/05

[#41941] [ruby-trunk - Bug #5851][Open] make check fails when compiling with GCC 4.7 - *** longjmp causes uninitialized stack frame *** — Vit Ondruch <v.ondruch@...>

12 messages 2012/01/06

[#41979] [ruby-trunk - Bug #5865][Open] Exception#== should return false if the classes differ — Hiro Asari <asari.ruby@...>

10 messages 2012/01/08

[#42003] [ruby-trunk - Bug #5871][Open] regexp \W matches some word characters when inside a case-insensitive character class — Gareth Adams <gareth@...>

14 messages 2012/01/09

[#42016] [ruby-trunk - Feature #5873][Open] Adopt FFI over DL — Heesob Park <phasis@...>

15 messages 2012/01/10

[#42149] [ruby-trunk - Feature #5899][Open] chaining comparsions. — Ondrej Bilka <neleai@...>

12 messages 2012/01/16

[#42164] [ruby-trunk - Feature #5903][Open] Optimize st_table (take 2) — Yura Sokolov <funny.falcon@...>

18 messages 2012/01/17

[ruby-core:42229] [ruby-trunk - Feature #5856] Feature: Raise any object

From: Kurt Stephens <redmine@...>
Date: 2012-01-25 18:32:06 UTC
List: ruby-core #42229
Issue #5856 has been updated by Kurt  Stephens.


One can rescue Exception (or Object); this also rescues SystemExit, Interrupt, etc.  There is plenty of code out there that rescues Exception but does not rethrow SystemExit and Interrupt; it's a common design mistake.  IMO, SystemExit is really a global control flow mechanism, not an exceptional condition; not debating this particular issue.

The issue is 3rd-parties often rescue Exception as a catch-all, to provide fallback, logging, etc; thus it prevents the raising objects that 3rd parties *should never* rescue accidentally.  rescue Object will trap *everything* and is usually considered bad style.  This patch does not prevent it.  Rather this patch, prevents 3rd-party code from accidentally rescuing exceptional conditions that they had not designed for.

Examples of exceptional control flows that 3rd-parties should not rescue accidentally via rescue Exception:

1) application container management
2) controlled termination of runaway worker process
3) hard Timeouts, that if incorrectly rescued, prevent a system from behaving according to real-world timing constraints.

Removing the "only Exceptions can be thrown" constraint increases flexibility; it allows objects that quack like an Exception to be thrown.

Exception is effectively a fragile base class, forcefully tied to the run-time; it prevents the use of the exception handling mechanism via duck-typing.


----------------------------------------
Feature #5856: Feature: Raise any object
https://bugs.ruby-lang.org/issues/5856

Author: Kurt  Stephens
Status: Feedback
Priority: Normal
Assignee: Yukihiro Matsumoto
Category: core
Target version: 


Feature: Raise any object

= Proposal

The ability to raise any object that conforms to the protocol of Exception.

= Problem

* The Exception subclass hierarchy is well-established.
* CRuby does not allow any object that behaves as an Exception to be raised, it must be a subclass of Exception.
* 3rd-party code often rescues Exception; e.g. for error recovery, retry and/or logging.
* Users need the ability to raise objects that would not normally be rescued by *any* code;
  e.g.: hard timeouts or custom signal handlers in an application.

= Solution

* ruby/eval.c: Remove make_exception() assertion rb_obj_is_kind_of(mesg, rb_mRaiseable).

= Implementation

* See attached patch or https://github.com/kstephens/ruby/tree/trunk-raise-any

= Example

* See test/ruby/test_raise_any.rb

= See also

* https://bugs.ruby-lang.org/issues/5818



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

In This Thread