Exception naming conventions: rely on module name?

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

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

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?
- 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)?

···

--
Posted via http://www.ruby-forum.com/.

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.

···

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

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

I LIT YOUR GEM ON FIRE!

Eric Hodel wrote:

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!

Thank you for your advice. I will follow it.
Ed