[#64210] Asking for clarification for exception handling usage — Rodrigo Rosenfeld Rosas <rr.rosas@...>
I've created a ticket for that but didn't get any feedback so I decided
[#64517] Fw: Re: Ruby and Rails to become Apache Incubator Project — Tetsuya Kitahata <kitahata@99.alumni.u-tokyo.ac.jp>
What do you think? >> Ruby developers
What benefits are there to this? I have a feeling that adding unnecessary
On Sat, 23 Aug 2014 22:43:46 -0700
Here I am a Japanese. Before moving anywhere else answer to our question first: what benefits?
tax issue with each other.
Forgot to assert my opinions:
[#64614] cowspace (work-in-progress) — Eric Wong <normalperson@...>
Hi all, I started working on a cowspace branch. Based on the mspace API
[#64615] [ruby-trunk - Feature #10181] [Open] New method File.openat() — oss-ruby-lang@...
Issue #10181 has been reported by Technorama Ltd..
I like this feature.
On 08/28/2014 02:53 PM, Eric Wong wrote:
Joel VanderWerf <joelvanderwerf@gmail.com> wrote:
On 08/29/2014 12:55 AM, Eric Wong wrote:
Joel VanderWerf <joelvanderwerf@gmail.com> wrote:
[#64627] [ruby-trunk - Feature #10182] [PATCH] string.c: move frozen_strings table to rb_vm_t — ko1@...
Issue #10182 has been updated by Koichi Sasada.
[#64671] Fwd: [ruby-changes:35240] normal:r47322 (trunk): symbol.c (rb_sym2id): do not return garbage object — SASADA Koichi <ko1@...>
Why this fix solve your problem?
(2014/08/30 8:50), SASADA Koichi wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
(2014/08/31 0:18), Eric Wong wrote:
[ruby-core:64211] Re: Asking for clarification for exception handling usage
To answer the first half of your question, the "cause" is an underlying
exception (inherited from $!), so you can use it to chain errors. For
example:
begin
begin
raise 'foo'
rescue => foo
raise 'bar'
end
rescue => bar
end
bar #=> #<RuntimeError: bar>
bar.cause == foo #=> true
As to the second half, the third parameter to #raise is an
optionally-overridden backtrace:
begin
raise RuntimeError, 'baz', %w[a b c]
rescue => ex
end
ex.backtrace #=> ["a", "b", "c"]
Passing an exception instance to #raise does the following:
begin
begin
raise 'foo'
rescue => foo
raise foo # re-raise
end
rescue => bar
end
foo.__id__ # => 70351312183760
bar.__id__ # => 70351312183760
begin
begin
raise 'foo'
rescue => foo
raise foo, 'bar' # copy and raise
end
rescue => bar
end
foo.__id__ # => 70071384070800
bar.__id__ # => 70071384070620
bar.cause == foo # => true
In the first case the backtrace for both foo and bar lists line 3; in the
second they have line 3 and 5 respectively. I've never heard of an
exception's #cause returning anything but an Exception instance or nil.
On 6 August 2014 06:01, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:
> I've created a ticket for that but didn't get any feedback so I decided to
> try asking in another way:
>
> https://bugs.ruby-lang.org/issues/10110
>
> I'd like to understand what is Exception#cause and what exactly does the
> third parameter of Kernel#raise.
>
> I've seen a code calling raise exception_instance, message rather than
> passing the exception class and the cause for the handled exception was a
> string rather than an Exception. I don't even know if this is a bug and if
> raise should fail if you pass an exception instance with a message as I
> don't really understand how exception handling works in Ruby and what to
> expect for Exception#cause and how to properly wrap an exception for
> logging purposes...
>
> If you could at least explain what Exception#cause is supposed to carry on
> and what the third argument of Kernel#raise does exactly by the specs I'd
> be a lot grateful.
>
> Thanks in advance,
> Rodrigo.
>
>
--
Matthew Kerwin
http://matthew.kerwin.net.au/