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.
On 02/13/2010 02:16 AM, Xeno C. 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
On Sat, Feb 13, 2010 at 03:10, Robert K.
[email protected] wrote:
    robert
–
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Sounds like Xeno is looking for something equivalent to Java’s
IllegalStateException:
http://java.sun.com/javase/6/docs/api/java/lang/IllegalStateException.html
As far as I know, Ruby doesn’t have a built-in exception with similar
semantics. So the best bet would be to define your own.
Robert K. 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
then there is
def validateThatThingMadeByPureVirtualMethodIsThere
unless theThingMMadeByPureVirtualMethodIsThere?
raise ScriptError, “That thingy isn’t there.”
end
end
Xeno C. wrote:
def myPureVirtualMethod
raise ScriptError, “This should never be called. Daughter Classes
MUST define
their own.”
end
raise NoMethodError perhaps?
def validateThatThingMadeByPureVirtualMethodIsThere
unless theThingMMadeByPureVirtualMethodIsThere?
raise ScriptError, “That thingy isn’t there.”
end
end
raise “That thingy isn’t there” # RuntimeError
class MissingThingyErrror < RuntimeError; end
raise MissingThingyError, “That thingy isn’t there”
On Sat, Feb 13, 2010 at 9:10 AM, Xeno C.
[email protected] 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
On Sat, Feb 13, 2010 at 9:10 AM, Xeno C.
[email protected] wrote:
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.
Christopher D. 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 …
Christopher D. 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.