From: "trans (Thomas Sawyer)" <transfire@...>
Date: 2012-03-31T11:05:31+09:00
Subject: [ruby-core:43977] [ruby-trunk - Feature #5898] raise and Exception#initialize


Issue #5898 has been updated by trans (Thomas Sawyer).


You can reject it, but this will eventually come up again b/c current behaviour is confusing, inconsistent and either overly limiting or not limiting enough depending on which side you come down on.

----------------------------------------
Feature #5898: raise and Exception#initialize
https://bugs.ruby-lang.org/issues/5898#change-25498

Author: trans (Thomas Sawyer)
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 2.0.0


Calling `#raise` with a `message` parameter passes the argument on the Exception class' initialize method. But it does not support any additional arguments if the initialize method has been defined otherwise. Nor is the last optional argument, `caller`, passed to the initializer. All of which makes for a rather confusing mishmash of an interface between `#raise` and `Exception#initialize`.

Ideally I would think whatever arguments are passed to `#raise` would likewise be passed on to `Exception#initialize`, e.g.

  class MyError < Exception
    def initialize(a,b)
      super("#{a} and #{b}")
    end
  end

  raise MyError, 'foo', 'bar'

Alas, because `caller` can be passed to `#raise` this causes an error, as it thinks `bar` ought to be the caller array. So unless others see a way around it that I do not, this idealized scenario simply is not possible.

So I propose a second best approach. Notice that if `caller` is passed to `#raise` it is not being passed on to the `#initialize` method unlike the `message` argument. Instead `#set_backtrace` is being used to set the caller. I propose that the `message` argument be handled in the same way, and a new method `#set_message(msg)` be added to the `Exception` class to handle it.

This would then allow the initializer of subclasses to be freed up to be defined in other ways, should a specialized exception be able to make good use of a variant interface Which, btw, is the exact circumstance I presently find myself in for one of my projects. Consequently I had no choice by to define the #initialize method to take an initial blank argument that will almost always be set to +nil+.



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