Feature #5866: ValidationError

• Status: Rejected
• Assignee: -
• Target version: -

[trans (Thomas Sawyer)]

I've come across this from time to time, where some piece of complex data, often (but not always) loaded from a file, doesn't conform to some set of validation requirements. I've never been quite sure what type of error to throw if the data doesn't conform. It's not exactly an ArgumentError, it's more complex then that and not necessarily coming in via method arguments, nor is it exactly a TypeError since it's not necessarily anything to do with a specific class. So I find myself falling back to Runtime error and rolling my own, but thinking it would be nice if there were a general purpose ValidationError to raise or subclass in these cases.

On 01/08/2012 04:57 AM, Thomas Sawyer wrote:

I've come across this from time to time, where some piece of complex
data, often (but not always) loaded from a file, doesn't conform to
some set of validation requirements. I've never been quite sure what
type of error to throw if the data doesn't conform. It's not exactly
an ArgumentError, it's more complex then that and not necessarily
coming in via method arguments, nor is it exactly a TypeError since
it's not necessarily anything to do with a specific class. So I find
myself falling back to Runtime error and rolling my own, but thinking
it would be nice if there were a general purpose ValidationError to
raise or subclass in these cases.

Why not subclass Syntax error, and put the class in a namespace
belonging to your particular validation requirements? This is more or
less what YAML does.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Feedback

It sounds like an application (or library) layer story.
Why does it need to be supported in the language layer?

[trans (Thomas Sawyer)]

SyntaxError? I suppose we might assume that's appropriate if YAML is doing it, but ScriptError is not a StandardError, rather it is a ScriptError, which I think means it's supposed to be for RUBY syntax errors only. Am I wrong to think that?

"It sounds like an application (or library) layer story. Why does it need to be supported in the language layer?"

Yes, but it's helpful to base an app/library's errors on a standard superclass that fits. If a type of exception is so very common then I think it makes sense for Ruby to have a standard exception for it. I think validation is a very clear case for that. And an example for it might well be the fore mentioned YAML's use of SyntaxError, where something like ValidationError might, it seems to me, be more appropriate.

[trans (Thomas Sawyer)]

Oops, that should read "but SyntaxError is not a StandardError"

[regularfry (Alex Young)]

Maybe:

class InputFormatError < IOError
end

?

--
Alex

[ko1 (Koichi Sasada)]

• Target version changed from 2.0.0 to 2.6

I changed target to next minor because no feedback there.

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[matz (Yukihiro Matsumoto)]

• Status changed from Feedback to Rejected

The term Validation may have different meaning upon applications. There's no reason to treat them uniformly.
In addition, we already have many ValidationError in many gems. Adding canonical ValidationError can cause incompatibility.

Matz.