Asp Forum
Home
|
Login
|
Register
|
Search
Forums
>
comp.lang.ruby
Exception naming conventions: rely on module name?
Edwin Fine
12/29/2006 5:50:00 PM
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-...
.
2 Answers
Eric Hodel
12/29/2006 9:39:00 PM
0
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.se...
I LIT YOUR GEM ON FIRE!
Edwin Fine
12/30/2006 3:59:00 AM
0
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.se...
>
> I LIT YOUR GEM ON FIRE!
Thank you for your advice. I will follow it.
Ed
Servizio di avviso nuovi messaggi
Ricevi direttamente nella tua mail i nuovi messaggi per
Exception naming conventions: rely on module name?
Inserendo la tua e-mail nella casella sotto, riceverai un avviso tramite posta elettronica ogni volta che il motore di ricerca troverà un nuovo messaggio per te
Il servizio è completamente GRATUITO!
x
Login to ForumsZone
Login with Google
Login with E-Mail & Password