Forum: Ruby-core [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one

F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-04-11 18:40
(Received via mailing list)
Issue #8257 has been reported by headius (Charles Nutter).

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-04-11 21:48
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


Links to implementation of "cause" rendering and Kernel#raise logic from
Rubinius:

"cause" rendering:
https://github.com/rubinius/rubinius/blob/master/k...

Kernel#raise:
https://github.com/rubinius/rubinius/blob/master/k...

Note that the changes almost exclusively affect rendering of exceptions
that bubble out; no other visible aspects of exceptions change with this
enhancement. This means that libraries can start using the feature
without consumers having to change any code.

This feature would also be useful for associate a low-level cause with
higher-level exceptions in core classes and standard library, such as
wrapping a low-level IO exception in an SSLError or net/* exception.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-38472

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
Dddf1d0b08d492bbf18d7b865db098d8?d=identicon&s=25 rkh (Konstantin Haase) (Guest)
on 2013-04-12 17:13
(Received via mailing list)
Issue #8257 has been updated by rkh (Konstantin Haase).


This would indeed be useful. We have built our own solutions for this
many times.

Should there also be a mechanism to rescue based on cause that's
transparent of wrapping exceptions?
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-38494

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-04-12 18:03
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


rkh (Konstantin Haase) wrote:
> Should there also be a mechanism to rescue based on cause that's transparent of
wrapping exceptions?

Exception::=== could be enhanced to search causes, but I'm dubious about
the utility of such an enhancement. It could also make
exception-handling slower; even though it's obviously *exception*
handling and doesn't necessarily need to be lightning fast, people still
occasionally use it for flow control inappropriately.

I'd probably punt on that one myself and see over time how common it is
that people rescue based on causes. I'd suspect it's pretty rare...such
a feature has never been considered for Java (as far as I know) even
though Java's Throwable has had "cause" forever.

Also want to avoid feature creep. Exception#cause is a nice, simple,
low-impact feature as described by me here.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-38497

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
Dddf1d0b08d492bbf18d7b865db098d8?d=identicon&s=25 rkh (Konstantin Haase) (Guest)
on 2013-04-14 15:33
(Received via mailing list)
Issue #8257 has been updated by rkh (Konstantin Haase).


I think allowing rescue lines to take other objects besides modules
would this would greatly ease building something in user code:

def caused_by(matcher)
  block = proc do |exception|
    matcher === exception or exception.cause && block[exception.cause]
  end
end

begin
  ...
rescue caused_by(NetworkError)
  ...
end

But I guess that's a separate feature request.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-38542

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-04-15 23:04
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


rkh (Konstantin Haase) wrote:
> I think allowing rescue lines to take other objects besides modules would this
would greatly ease building something in user code:
...
> But I guess that's a separate feature request.

Yeah, it might be nice, but there might also be optimization concerns.
You're right though, it should indeed be a separate feature request, and
it's certainly applicable to more than just Exception#cause.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-38577

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-04-28 00:20
(Received via mailing list)
(2013/04/12 1:40), headius (Charles Nutter) wrote:
> * A new set of Kernel#raise overloads that accept (as a trailing argument,
probably) the "cause" exception.

(1) introduce new keyword?

 example: raise(..., cause: e)

(2) How about to use `$!' forcibly?
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-04-28 00:20
(Received via mailing list)
(2013/04/28 7:19), SASADA Koichi wrote:
> (2) How about to use `$!' forcibly?

because I think Exception#cause= is not cool.
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-04-28 01:00
(Received via mailing list)
On Sat, Apr 27, 2013 at 5:19 PM, SASADA Koichi <ko1@atdot.net> wrote:
> (1) introduce new keyword?
>
>  example: raise(..., cause: e)

Yeah, that's not bad. Keywords allow us to avoid changing the
signature in new/incompatible/non-forward-compatible ways.

> (2) How about to use `$!' forcibly?

Do you mean automatically stick $! into Exception#cause when creating
(or perhaps better, when raising) a new Exception? That's not a bad
idea.

Interestingly, java.lang.Throwable also does not allow setting the
cause. You can set it during init or after init *at most once*. Here's
JavaDoc for it:
http://docs.oracle.com/javase/7/docs/api/java/lang...)

I quote: "This method can be called at most once. It is generally
called from within the constructor, or immediately after creating the
throwable. If this throwable was created with Throwable(Throwable) or
Throwable(String,Throwable), this method cannot be called even once."

Java 7 also added an additional mechanism for attaching exceptions,
called "supressed exceptions".
http://docs.oracle.com/javase/7/docs/api/java/lang...)

This mechanism was added for exceptions that are not really the
*cause*, but which are related. For example, an IO read operation
raises an error, and while handling that error and attempting to close
the stream a second error is raised. The read error did not cause the
close error, but you don't want to lose either. You raise the close
error with the read error attached as "suppressed".

I think for purposes of this feature, adding cause, which can be
initialized during construction only, would be sufficient. I have no
strong opinion about automatically using $! as the cause, but it might
be nice.
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-04-28 01:09
(Received via mailing list)
(2013/04/28 7:59), Charles Oliver Nutter wrote:
>> > (2) How about to use `$!' forcibly?
> Do you mean automatically stick $! into Exception#cause when creating
> (or perhaps better, when raising) a new Exception? That's not a bad
> idea.

Yes.

> I think for purposes of this feature, adding cause, which can be
> initialized during construction only, would be sufficient. I have no
> strong opinion about automatically using $! as the cause, but it might
> be nice.

Cool.

Summary:
(1) raise method captures $! as @cause.
(2) Adding new method Exception#cause returns @cause.

* I'm not sure #cause is good name.
  Too short?
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-04-28 21:11
(Received via mailing list)
On Sat, Apr 27, 2013 at 6:09 PM, SASADA Koichi <ko1@atdot.net> wrote:
> Summary:
> (1) raise method captures $! as @cause.
> (2) Adding new method Exception#cause returns @cause.
>
> * I'm not sure #cause is good name.
>   Too short?

It seems ok to me, since Java's Throwable uses the same name (but I am
perhaps a bit biased.

.NET's Exception calls it the BaseException, via GetBaseException. I
think "base" or "base_exception" not as good as "cause".

I guess the next step is a patch.

- Charlie
Dddf1d0b08d492bbf18d7b865db098d8?d=identicon&s=25 rkh (Konstantin Haase) (Guest)
on 2013-04-29 09:23
(Received via mailing list)
Issue #8257 has been updated by rkh (Konstantin Haase).


I love the idea of having $! be the cause. It would also mean instant
adoption.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-39033

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-09-27 13:05
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


Any further comments here? I might be able to do part of the
implementation, but I don't know how to automatically stick $! into
cause. I'd like to see this in 2.1.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42036

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-10-01 02:39
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).

Target version set to Ruby 2.1.0


----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42121

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 ko1 (Koichi Sasada) (Guest)
on 2013-10-01 09:55
(Received via mailing list)
Issue #8257 has been updated by ko1 (Koichi Sasada).

Assignee set to matz (Yukihiro Matsumoto)

I'm positive about this feature.

Matz, what do you think about?

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42135

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 matz (Yukihiro Matsumoto) (Guest)
on 2013-10-09 15:28
(Received via mailing list)
Issue #8257 has been updated by matz (Yukihiro Matsumoto).


Hi,

* Fundamentally accepted.
* I am against #cause=
* It's OK that #raise to have cause: keyword argument to specify cause
* I am not sure automagical capturing of $! would not cause wrong
capturing or not

Matz.

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42373

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-10-09 17:29
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


matz (Yukihiro Matsumoto) wrote:
> * Fundamentally accepted.

Hooray!

> * I am against #cause=

java.lang.Throwable does not have #setCause, so I agree. It does have
#initCause, which can only be called once (if cause has not already been
provided via constructor)...but I have never used it.

> * It's OK that #raise to have cause: keyword argument to specify cause

Agreed. Unfortunately this would still break backward-compatibility,
since it will count as an extra argument on older Ruby versions. This
might be the biggest justification for $! capturing.

> * I am not sure automagical capturing of $! would not cause wrong capturing or
not

There are a few small risks:

* Many layers of exceptions being raised as an error propagates out
would all be chained. This could cause more information/data/memory than
necessary to be retained.
* Lower layers may not want higher layers to have access to the causing
error for security or encapsulation reasons.
* Too much magic?

But I think the benefits may outweigh them:

* I can't think of any concrete examples of the above risks.
* Automatic adoption; all exceptions caused by other exceptions will
immediately show their lineage.
* Reduced backward incompatibility (other than adding #cause) since
users won't have to use the constructor to capture cause exception (of
course, I still think we should have the cause constructor too).

I think the output of exception backtraces should also be enhanced to
show cause exception's trace, as in the JVM. This could cause a problem
for tools that parse the backtrace, though (IMO nobody should ever parse
backtraces and expect that to be stable).
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42384

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-11-10 15:56
(Received via mailing list)
Issue #8257 has been updated by nobu (Nobuyoshi Nakada).


Automagically captured exceptions doesn't feel `cause' to me, now.
It might be irrelevant to the previously rescued exception.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42838

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-11-12 19:33
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


nobu (Nobuyoshi Nakada) wrote:
> Automagically captured exceptions doesn't feel `cause' to me, now.
> It might be irrelevant to the previously rescued exception.

That's true, but will that be the exception or the rule? It seems to me
that most "hidden" or "suppressed" exceptions will be direct triggers
for the actually-raised exception.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42886

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
87e61e351b823e19b4a62a896d2af0d4?d=identicon&s=25 henry.maddocks (Henry Maddocks) (Guest)
on 2013-11-13 00:04
(Received via mailing list)
Issue #8257 has been updated by henry.maddocks (Henry Maddocks).


How is this different to 'wrapping' an exception? Eg.

http://www.jayway.com/2011/05/25/ruby-an-exception...


----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42891

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-11-13 00:46
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


henry.maddocks (Henry Maddocks) wrote:
> How is this different to 'wrapping' an exception? Eg.
>
> http://www.jayway.com/2011/05/25/ruby-an-exception...

Not much different, but built-in and automatically available.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-42892

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-11-26 21:57
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


I think we still need to add Exception.new(:cause => ex) to allow
constructing an exception with a *specific* cause. The $! capturing is
great but often there may be more than one exception in play.

This needs to happen before 2.1 final.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43178

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-12-07 13:15
(Received via mailing list)
Issue #8257 has been updated by nobu (Nobuyoshi Nakada).


What about the backward compatibility?
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43495

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-12-09 07:10
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


nobu: Because :cause is opt-in, I am not concerned about the backward
compat. You'd have to be committing to 2.1 in order to start using that
feature, and I think it will be slow to adopt in any case.

It would also be possible to monkey-patch older versions to just ignore
the options.

I think we should add the option for future use, because it *is* needed,
and we have to add it some time.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43541

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-12-10 15:24
(Received via mailing list)
Issue #8257 has been updated by nobu (Nobuyoshi Nakada).


Carelessly, I implemented `raise cause: ex` but not
`Exception.new(cause: ex)`, and nearly committed it.
Do you prefer the latter?
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43574

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-12-11 05:16
(Received via mailing list)
(2013/12/10 23:24), nobu (Nobuyoshi Nakada) wrote:
> Carelessly, I implemented `raise cause: ex` but not `Exception.new(cause: ex)`,
and nearly committed it.
> Do you prefer the latter?

How about to simply add Exception#cause= only?

This is because:

  * Setting "cause" is not common usecase (nobody care about it)
    Some long steps such as
       e = Exception.new(...)
       e.cause =...
       raise e"
    is acceptable for unusual cases.

  * No compatibility issue with raise()

However, matz is against "cause=" by [ruby-core:57773].
Because he doesn't want to introduce any states.
I also agree this point.
2abdb50caf0dc5b510330f68b02db8e4?d=identicon&s=25 rosenfeld (Rodrigo Rosenfeld Rosas) (Guest)
on 2013-12-11 12:10
(Received via mailing list)
Issue #8257 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


Actually, the only reason I don't use it is because it's not possible,
but I'd most probably always send along the cause if this was supported,
so I prefer a concise way to do that.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43611

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
2abdb50caf0dc5b510330f68b02db8e4?d=identicon&s=25 rosenfeld (Rodrigo Rosenfeld Rosas) (Guest)
on 2013-12-11 12:14
(Received via mailing list)
Issue #8257 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


And sometimes a Runtime exception would be fine to me, so `raise "Some
explanation", cause: ex` would be great, but sometimes I need to wrap
the original exception in some specific one. In that latter case, I'd
prefer to be able to specify the cause with
`CustomException.new("message", cause: ex)`. I'm usually interested in
keeping the full backtrace in a simple way when doing that...
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43612

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-12-11 13:09
(Received via mailing list)
Issue #8257 has been updated by nobu (Nobuyoshi Nakada).


rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
> sometimes I need to wrap the original exception in some specific one.

Just wrapping in a new exception but don't raise it?
How frequent is such case?


----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43613

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
2abdb50caf0dc5b510330f68b02db8e4?d=identicon&s=25 rosenfeld (Rodrigo Rosenfeld Rosas) (Guest)
on 2013-12-11 16:28
(Received via mailing list)
Issue #8257 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


Yes, raising it too.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43615

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
2abdb50caf0dc5b510330f68b02db8e4?d=identicon&s=25 rosenfeld (Rodrigo Rosenfeld Rosas) (Guest)
on 2013-12-11 16:34
(Received via mailing list)
Issue #8257 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


I believe you think I should write this instead:

raise WrappedException.new("message"), cause: ex

I wouldn't mind doing that but if I ever had to store the exception
without raising it then it wouldn't be possible to do so, right? But in
that case I could also store the cause separately, so it isn't really a
big deal.

I wouldn't mind to add cause just to raise...
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43616

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-12-12 09:00
(Received via mailing list)
Issue #8257 has been updated by nobu (Nobuyoshi Nakada).


rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
> I believe you think I should write this instead:
>
> raise WrappedException.new("message"), cause: ex

I think this is more common in ruby:
  raise WrappedException, "message", cause: ex


----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43623

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
4dea430d31b993abaf41cd9b54f8128d?d=identicon&s=25 Avdi Grimm (avdi)
on 2013-12-25 21:15
(Received via mailing list)
I've been digging into this feature now that 2.1 is released, and I'm a
little confused. In the final implementation, can #cause only be set
from
$!? None of the other methods for setting the cause discussed in this
thread seem to work, and for that matter I don't see any changes to the
#raise or Exception#initialize methods to support explicitly setting a
cause.
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-12-29 16:19
(Received via mailing list)
Issue #8257 has been updated by headius (Charles Nutter).


Unfortunately it doesn't look like anything other than $! logic for this
made it into 2.1. I was hoping we'd get either the constructor or a
one-time-only #cause= but there was still some debate about which way to
go.

Since the base #cause and $! logic made it in, perhaps we should call
this bug closed as of 2.1 and add a new bug for additional ways to
initialize the exception cause.
----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-43938

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: Ruby 2.1.0


Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
0ea7f61aec8fee539be0cf39b7bab77c?d=identicon&s=25 unknown (Guest)
on 2014-02-02 16:11
(Received via mailing list)
Issue #8257 has been updated by Benoit Daloze.


`raise ErrorClass, msg, cause: cause` was implemented with the rest in
r44473.

    e = (
    begin
      raise ArgumentError, "arg error"
    rescue
      nie = NotImplementedError.new("nie")
      raise StandardError, "stderr", cause: nie
    end) rescue $!
    e.cause # => #<NotImplementedError: nie>

But the cause is not shown in the error output, which I think is now the
most important step forward.

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-44891

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category:
* Target version: Ruby 2.1.0
----------------------------------------
Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
8cbb39dadafaf2287a83a13ee4981ec9?d=identicon&s=25 unknown (Guest)
on 2014-02-05 04:49
(Received via mailing list)
Issue #8257 has been updated by Usaku NAKAMURA.

Related to Bug #9338: Build failure of trunk with MSVC 2013 added

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-44959

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category:
* Target version: Ruby 2.1.0
----------------------------------------
Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
9361878d459f1709feec780518946ee5?d=identicon&s=25 unknown (Guest)
on 2014-06-17 04:34
(Received via mailing list)
Issue #8257 has been updated by Yui NARUSE.


Vagrant hits the incompatibility:
https://github.com/mitchellh/vagrant/blob/master/p...

```ruby
 raise Vagrant::Errors::VBoxManageError,
                 :command => command.inspect,
                 :stderr  => r.stderr
```

it raies ArgumentError: unknown keyword: command, stderr.

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-47254

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category:
* Target version: Ruby 2.1.0
----------------------------------------
Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2014-06-17 05:38
(Received via mailing list)
Issue #8257 has been updated by Nobuyoshi Nakada.

Status changed from Open to Closed
% Done changed from 0 to 100

Applied in changeset ruby-trunk:r46456.

----------
eval.c: pass unknown options

* eval.c (extract_raise_opts): pass unknown options to the
  exception, so that exception class can receive a hash argument.
  [ruby-core:63203] [Feature #8257]

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-47255

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category:
* Target version: Ruby 2.1.0
----------------------------------------
Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2014-07-20 22:21
(Received via mailing list)
Issue #8257 has been updated by Charles Nutter.


I agree with Benoit that the cause exception should be reflected in the
error output, as on the JVM. What are the objections?

I do *not* believe this should show up in #backtrace since I have no
idea how it would be formatted. This also lines up with the JVM
(printStackTrace and friends print cause, but getStackTrace only returns
trace for target exception).

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-47939

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category:
* Target version: Ruby 2.1.0
----------------------------------------
Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2014-07-21 15:22
(Received via mailing list)
(2014/07/21 1:50), headius@headius.com wrote:
> I agree with Benoit that the cause exception should be reflected in the error
output, as on the JVM. What are the objections?

What happen on exception from deep backtrace, occurred by other more
deeper exception?  Show all long two backtraces?
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 unknown (Guest)
on 2014-07-21 15:24
(Received via mailing list)
Issue #8257 has been updated by Koichi Sasada.


 (2014/07/21 1:50), headius@headius.com wrote:
 > I agree with Benoit that the cause exception should be reflected in
the error output, as on the JVM. What are the objections?

 What happen on exception from deep backtrace, occurred by other more
 deeper exception?  Show all long two backtraces?

 --
 // SASADA Koichi at atdot dot net

----------------------------------------
Feature #8257: Exception#cause to carry originating exception along with
new one
https://bugs.ruby-lang.org/issues/8257#change-47947

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category:
* Target version: Ruby 2.1.0
----------------------------------------
Often when a lower-level API raises an exception, we would like to
re-raise a different exception specific to our API or library. Currently
in Ruby, only our new exception is ever seen by users; the original
exception is lost forever, unless the user decides to dig around our
library and log it. We need a way to have an exception carry a "cause"
along with it.

Java has getCause/setCause and standard constructors that take a cause
exception. Printing out an exception's backtrace then reports both that
exception and any "cause" exception.

Rubinius has added a similar feature:
https://gist.github.com/dbussink/b2e01e51d0c50b27004f

The changes required for this feature are pretty benign:

* Exception#cause and #cause= accessors.
* A new set of Kernel#raise overloads that accept (as a trailing
argument, probably) the "cause" exception.
* Modifications to backtrace-printing logic to also display backtrace
information from the "cause" exception (and in turn, from any nested
"cause" exceptions).

There's some discussion here about alternatives to #cause, none of which
are quite as elegant as having it built in:
http://www.skorks.com/2013/04/ruby-why-u-no-have-n...
This topic is locked and can not be replied to.