What is the best exception to use for bad Data State?
in [Ruby]
|
Prev: Is there a way to get a method to always run at the end of anydescendent's initialize method?
Next: Rmagick DNG
From: Ben Bleything on 13 Feb 2010 12:46 On Sat, Feb 13, 2010 at 9:10 AM, Xeno Campanoli <xeno.campanoli(a)gmail.com> wrote: > For now I am using "ScriptError". I was using "SyntaxError", but I think > that was just wrong. Here are some places: > > I have what I want to be pure virtual methods in a base class: > > def myPureVirtualMethod > raise ScriptError, "This should never be called. Daughter Classes > MUST define their own." > end I use NotImplementedError for base methods in a "virtual" class. > def validateThatThingMadeByPureVirtualMethodIsThere > unless theThingMMadeByPureVirtualMethodIsThere? > raise ScriptError, "That thingy isn't there." > end > end Absolutely NotImplementedError here too. Ben
From: Christopher Dicely on 13 Feb 2010 18:25 On Sat, Feb 13, 2010 at 9:10 AM, Xeno Campanoli <xeno.campanoli(a)gmail.com> wrote: > Robert Klemme wrote: >> >> On 02/13/2010 02:16 AM, Xeno Campanoli wrote: >>> >>> I don't want to use "ArgumentError" as this is a matter of data that may >>> be programmed in a daughter class, and is not necessarily an argument. >>> Specifically, the state of some object variables in this case. >> >> Can you provide more context information? Â When do you want to throw? >> >> Kind regards >> >> Â Â robert >> > > For now I am using "ScriptError". Â I was using "SyntaxError", but I think > that was just wrong. Â Here are some places: > > I have what I want to be pure virtual methods in a base class: From what I've seen, it seems more idiomatic in Ruby not to define "pure virtual" methods, and instead describe methods that must be provided in child classes in the parent classes docs. Pure virtual methods in static languages mostly exist to allow code to compile that targets the generic interface of the class, but since Ruby doesn't have static variable typing and compile-time checking that method calls are valid for the type of the variable they are called against, there doesn't seem to be a whole lot of reason to actually define a pure virtual method. If a call is made to an undefined method, you'll normally (unless you've, e.g., done something with method_missing that redirects the call) get a NoMethodError exception thrown.
From: Albert Schlef on 13 Feb 2010 19:10 Christopher Dicely wrote: > [in Ruby] there doesn't seem to be a whole lot of reason to > actually define a pure virtual method. [...] > instead describe methods that must be > provided in child classes in the parent classes docs Documenting a method somewhere in the parent docs is like putting a needle inside a haystack. You'll find it there only if you specifically search for it. And you'll search for it only if you know it's supposed to exist, and this is probably not going to happen. Defining "abstract" (or "virtual") methods in Ruby is useful for documentation. -- Posted via http://www.ruby-forum.com/.
From: Albert Schlef on 13 Feb 2010 19:13
Christopher Dicely wrote: > If a call is made to an undefined method, you'll normally (unless > you've, e.g., done something with method_missing that redirects the > call) get a NoMethodError exception thrown. But NoMethodError is also raised if you have a typo in your code. So when you're going to see it you're going to think that you've mistyped something, or that your library isn't updated for Ruby 1.9, or has a bug, or ... -- Posted via http://www.ruby-forum.com/. |