Re: General API design question: FooError vs Foo::Error

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:

  1. 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.

  1. 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?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs