[#74190] [Ruby trunk Feature#12134] Comparison between `true` and `false` — duerst@...
Issue #12134 has been updated by Martin D端rst.
3 messages
2016/03/07
[#74269] Type systems for Ruby — Rob Blanco <ml@...>
Dear ruby-core,
5 messages
2016/03/10
[#74395] [Ruby trunk Feature#12142] Hash tables with open addressing — shyouhei@...
Issue #12142 has been updated by Shyouhei Urabe.
3 messages
2016/03/17
[ruby-core:74457] [Ruby trunk Feature#11951] `RubyVM::InstructionSequence.compile` should return the error message within the raised error
From:
nobu@...
Date:
2016-03-19 03:04:59 UTC
List:
ruby-core #74457
Issue #11951 has been updated by Nobuyoshi Nakada. https://github.com/ruby/ruby/compare/trunk...nobu:feature/11951-iseq-compile-error ---------------------------------------- Feature #11951: `RubyVM::InstructionSequence.compile` should return the error message within the raised error https://bugs.ruby-lang.org/issues/11951#change-57581 * Author: Tsuyoshi Sawada * Status: Open * Priority: Normal * Assignee: ---------------------------------------- When `RubyVM::InstructionSequence.compile` raises a syntax error, it outputs the syntax error message to `$stderr`, and then raises a `SyntaxError` anyway, whose message is simply: `"compile error"`. I don't think this is useful. For example, if I want to analyze within Ruby code whether a certain string is syntactically correct Ruby code, I would have to reasign `$stderr` to something such as `StringIO.new`, run `RubyVM::InstructionSequence.compile`, rescue the syntax error, (but instead of reading the error message from the error), read the error message by doing `$stderr.string`. This is cumbersome. On the other hand, there is `eval`, which also can raise a SyntaxError. But with `eval`, the error message comes out with the raised error, and is useful. I don't see any reason why `RubyVM::InstructionSequence.compile` should behave differently from `eval` with respect to returning the error message. I request `RubyVM::InstructionSequence.compile` to return the error message as the message on the raised error rather than directly printing it to `$stderr`. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>