Exception naming conventions: rely on module name?

Discussion in 'Ruby' started by Edwin Fine, Dec 29, 2006.

  1. Edwin Fine

    Edwin Fine Guest

    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/.
     
    Edwin Fine, Dec 29, 2006
    #1
    1. Advertising

  2. Edwin Fine

    Eric Hodel Guest

    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 - - http://blog.segment7.net

    I LIT YOUR GEM ON FIRE!
     
    Eric Hodel, Dec 29, 2006
    #2
    1. Advertising

  3. Edwin Fine

    Guest

    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 - - http://blog.segment7.net
    >
    > I LIT YOUR GEM ON FIRE!


    Thank you for your advice. I will follow it.
    Ed
     
    , Dec 30, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harman
    Replies:
    1
    Views:
    2,545
    Moiristo
    Jul 28, 2006
  2. grackle

    module naming conventions

    grackle, Jan 14, 2008, in forum: Python
    Replies:
    9
    Views:
    472
    Jorgen Grahn
    Jan 17, 2008
  3. Emanuele D'Arrigo

    Can I rely on...

    Emanuele D'Arrigo, Mar 19, 2009, in forum: Python
    Replies:
    6
    Views:
    331
    Bruno Desthuilliers
    Mar 20, 2009
  4. Emanuele D'Arrigo

    Can I rely on...

    Emanuele D'Arrigo, Mar 19, 2009, in forum: Python
    Replies:
    3
    Views:
    281
    R. David Murray
    Mar 19, 2009
  5. Tim Johnson

    PEP for module naming conventions

    Tim Johnson, Mar 11, 2011, in forum: Python
    Replies:
    3
    Views:
    529
    Jonathan Gossage
    Mar 17, 2011
Loading...

Share This Page