[#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:64237] [ruby-trunk - Bug #10110] Exception handling is not well documented
Issue #10110 has been updated by Rodrigo Rosenfeld Rosas.
Ok, I could get a better understanding of how this works from another message in the mailing list but there's something missing in the documentation.
Here is the problem:
~~~
class CustomError < StandardError
attr_reader :cause
def initialize(cause = nil)
@cause = cause
end
end
~~~
So, this is the first question. My coworker insists this is a valid way of describing an exception. If that's true, then it means the documentation of Kernel#raise is incomplete. The documentation states that the "second parameter sets the message associated with the exception".
But it's not how it currently works given the class above and this snippet:
~~~
raise CustomError, 'custom error message'
~~~
If you rescue this error you'll get e.cause == 'custom error message'.
On the other hand, if you use:
~~~
raise CustomError.new, 'custom error message'
~~~
Then it works fine. The cause would be nil in that case while the error message would indeed be set to 'custom error message' as stated in the documentation.
From my point of view something is missing, and some of the actions below should be taken:
1 - if creating exceptions classes like demonstrated above are supported by Ruby then we should either:
1.a - fix Kernel#raise to properly set the error message from the second argument as stated in its docs
1.b - fix the documents to explain how the exception is instantiated depending on the first argument class
2 - Otherwise (writing such classes is not supported) it should be explained in the Exception class whether the constructor is allowed to be overriden and if so how their arguments are expected to be like.
Please let me know where is the bug: the exception definition, the raise behavior or the raise documentation?
----------------------------------------
Bug #10110: Exception handling is not well documented
https://bugs.ruby-lang.org/issues/10110#change-48227
* Author: Rodrigo Rosenfeld Rosas
* Status: Open
* Priority: Normal
* Assignee: Zachary Scott
* Category: doc
* Target version:
* ruby -v: 2.1.2
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
Exception#cause has no documentation at all:
http://www.ruby-doc.org/core-2.1.2/Exception.html#method-i-cause
This is the documentation for Kernel.raise:
With no arguments, raises the exception in $! or raises a RuntimeError if $! is nil. With a single String argument, raises a RuntimeError with the string as a message. Otherwise, the first parameter should be the name of an Exception class (or an object that returns an Exception object when sent an exception message). The optional second parameter sets the message associated with the exception, and the third parameter is an array of callback information. Exceptions are caught by the rescue clause of begin...end blocks.
It's not clear how to get this last argument, i.e., the "callback information". What is a callback information? Does this relate to Exception#cause or Exception#backtrace?
This is all very confusing to me and it would help if someone could please make it clear...
--
https://bugs.ruby-lang.org/