FooError to
Foo::Error. Take a look at TimeoutError vs Timeout::Error,
for example.
Is there a reason the latter is preferred these days? Just curious.
Any thoughts? Anyone?
Dan
This communication is the property of Qwest and may contain confidential
or
privileged information. Unauthorized use of this communication is
strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and
destroy
all copies of the communication and any attachments.
On 6/28/06, Berger, Daniel [email protected] wrote:
FooError to
Foo::Error. Take a look at TimeoutError vs Timeout::Error,
for example.
Is there a reason the latter is preferred these days? Just curious.
Any thoughts? Anyone?
Dan
My two best guesses would be:
-
shorter code – from within the Timeout class you would have to write
raise TimeoutError, “error message”
vs.
raise Error, "error message"
So it could just be fewer keystrokes for the developer. However, I
think the second guess has more merit.
- smart use of namespaces
Putting the Error within the Timeout class namespace let’s you quickly
identify which class defined the method that raised the exception.
For example
class A
class Error < Exception; end
def a() raise Error, “from #{self.class.name}”
end
class B < A
class Error < Exception; end
def b() raise Error, “from #{self.class.name}”
end
A.new.a
B.new.a
B.new.b
→ A::Error: from A
→ A::Error: from B
→ B::Error: from B
So, even though we invoke a() through and instance of B, the exception
tells us that the error came from one of A’s methods. The only catch
with this method is if B fails to define its own Error class. Then
all exceptions will look like they’re coming from A.
Any other thoughts out there?