[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>

In This Thread

Prev Next