From: Yukihiro Matsumoto <matz@...>
Date: 2011-12-28T12:40:34+09:00
Subject: [ruby-core:41836] [ruby-trunk - Feature #5818] Feature: Raiseable


Issue #5818 has been updated by Yukihiro Matsumoto.


Separate the proposal into two: (a) allow non-Exception object to be raised. (b) Raiseable.  And I will refuse (b).  Currently, I see no good reason for (a), but you can try to persuade me.

Matz.
----------------------------------------
Feature #5818: Feature: Raiseable
https://bugs.ruby-lang.org/issues/5818

Author: Kurt  Stephens
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


= Proposal

The ability to raise any object that is a Raiseable.

= 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

* A "Raiseable" module implements all of the methods currently defined in Exception.
* Exception class includes Raiseable module.
* ruby/eval.c: make_exception() asserts rb_obj_is_kind_of(mesg, rb_mRaiseable), 
instead of rb_obj_is_kind_of(mesg, rb_cException).  
* Users should avoid "rescue Raiseable" in usual circumstances.

= Other Ideas not implemented here:

* Remove the obj_is_kind_of(mesg, rb_mRaiseable) restriction to allow pure duck-typing.
* Clean up the ivar names (@bt, @mesg) and method names (set_backtrace).

= Example

(({
    raiseable = Class.new do
      include Raiseable
      def self.exception *args; new *args; end
    end

    begin
      raise raiseable, "this must be handled"
      assert(false)
    rescue Exception
      assert(false)
    rescue Raiseable
      assert(true)
    end
}))




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