Issue #8863 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Feedback

Hmm, defining the behavior to raise UndefinedBehaviorError seems contradiction to me.

Matz.

----------------------------------------
Feature #8863: New error class: UndefinedBehaviorError
https://bugs.ruby-lang.org/issues/8863#change-41629

Author: alexeymuranov (Alexey Muranov)
Status: Feedback
Priority: Normal
Assignee: 
Category: 
Target version: 


=begin
I propose to consider introducing a new error class: (({UndefinedBehaviorError})) (or (({UnspecifiedBehaviorError}))).  It would be somewhat similar to (({NotImplementedError})), but it would mean that the behavior is actually unspecified, but may be defined in future versions (of Ruby or of the application).

The purpose is to raise it in "edge cases" of a newly introduced feature, to avoid users' relying on some unintended behavior, and to be able to change the behavior or to raise a different type of error in a future version.

I was thinking about a possible need for something like this in relation to (({Enumerable#to_h})) #7292.
=end



-- 
http://bugs.ruby-lang.org/