Project

General

Profile

Actions

Feature #8863

closed

New error class: UndefinedBehaviorError

Added by alexeymuranov (Alexey Muranov) over 10 years ago. Updated about 10 years ago.

Status:
Feedback
Assignee:
-
Target version:
-
[ruby-core:57021]

Description

=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

Updated by alexeymuranov (Alexey Muranov) over 10 years ago

Well, maybe just leaving the behavior unspecified is enough, i don't know. But raising an error would reduce a chance of breaking a program of someone who has not read the documentation well.

Updated by matz (Yukihiro Matsumoto) over 10 years ago

  • Status changed from Open to Feedback

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

Matz.

Updated by alexeymuranov (Alexey Muranov) over 10 years ago

matz (Yukihiro Matsumoto) wrote:

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

Matz.

It sounds like it, but my thought was that a user may catch other types of errors and use them meaningfully, but here it would be clearly advised not to rely on catching it. I am not sure it is useful, i agree with Feedback status. I thought first that maybe some other class of Errors can be appropriate, like NotImplementedError, but it does not match the meaning. It is to leave options open when introducing a new feature.

Actions #4

Updated by alexeymuranov (Alexey Muranov) about 10 years ago

After thinking about it, and since there is no feedback, i think this my feature request may be closed. I think handling special cases or catching exceptions to raise another exception is an unnecessary complication. Documentation should suffice.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0