From: Eric Hodel <drbrain@...7.net>
Date: 2006-12-30T06:39:11+09:00
Subject: Re: Exception naming conventions: rely on module name?

On Dec 29, 2006, at 09:50, Edwin Fine wrote:

> I am wondering about design alternatives regarding exception naming in
> Ruby. Is there a naming convention for exceptions that are declared
> inside a module?
>
> For example, let's say we have a module named MP3, and we want to  
> have a base exception for MP3-related errors. There are two basic  
> choices I am considering here:
>
> module MP3
>    class MP3Error < StandardError; end # Alternative 1
>    class Error < StandardError; end # Alternative 2
> end

I typically use #2

> Outside the module, Error would be disambiguated by MP3 (MP3::Error).
> However, I am uneasy about this, because of the following situation.
> Imagine someone has some existing code that mixes in module Other:
>
> module Other
>    class Error < StandardError; end
> end
>
> class Foo
>   include Other
>   def Foo.oops
>     raise Error, "Who am I?"
>   rescue Error => e
>     puts "#{e} #{e.class.name}"
>   end
> end
>
> Foo.oops # Who am I? Other::Error

Always fully qualify.

> Now this hapless person mixes in MP3.
>
> class Foo
>   include Other
>   include MP3
>   def Foo.oops
>     raise Error, "Who am I?"
>   rescue Error => e
>     puts "#{e} #{e.class.name}"
>   end
> end
>
> Foo.oops # Who am I? MP3::Error
>
> - Is this a real concern?

No.  Fully qualify and it won't be a problem.

> - Do you think it would be better to have exception names that are  
> less likely to clash at the cost of some duplication (e.g.  
> MP3::MP3Error instead of MP3::Error)?

MP3::MP3Error is redundant.  There is no problem if you raise  
MP3::Error instead.  If a consumer of your library decides to omit  
Error that's their bug, not yours.

-- 
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!