in reply to RFC: A better name for an exception handling module?

You should keep in mind that a name *::Lite would look very appealing to many programmers who already have to include lots of module monsters into their code.

If your module just seems to differ in the details from the other modules you might as well just take a nondescriptive name. Rose::DB or Moose got used for their merits and not for a catchy name after all.

But the overall impression I get from your module description is that its output is just more informative than all the other Exception modules, so how about

Exception::Descriptive

Exception::Informative

Exception::Clear

Exception::More

And I, for one, welcome our new exception overlord ;-)

  • Comment on Re: RFC: A better name for an exception handling module?

Replies are listed 'Best First'.
Re^2: RFC: A better name for an exception handling module?
by ELISHEVA (Prior) on Dec 22, 2010 at 18:43 UTC

    Thanks for your feedback. I like the name Exception::Clear and your point about "::Lite" is well taken.

    I am concerned by the perception that he overall impression I get from your module description is that its output is just more informative than all the other Exception modules

    This points to a failure on my part to clearly describe the exception class and what it adds. Better management of the actual creation of exceptions was also a goal. In fact it was the original motivation. I only added the improved debugging output later on as I put the exception class into production. In all of the other modules I could find, you can define properties and you can define a message, but if there is any connection between the two, you have to set it up outside the exception, or else create a subclass of the module.

    In Exception::Class and pretty much all of the other OOPish CPAN exception modules you have to do something like this:

    #... at the start of your code ... # notice how exception definition and message format # string constant are in two different places and need # to be manually coordinated by the programmer. use Exception::Class { 'Exception::Copy::Mine' { fields => [qw(from to)]; } # ... lots of other exceptions here ... } my $MSG_COPY='Could not copy A.txt to B.txt"; ... later on when you throw the exception ... # notice the repetition in the use of exception # properties; the repetition is error prone and adds # unnecessary extra typing my $sMsg = sprintf($MSG_COPY, 'A.txt', 'B.txt'); Exception::Copy::Mine->throw(error => $sMsg , from => 'A.txt' , to => 'B.txt');

    As far as I can see, none of the other modules allow you do do something succinct and easy to maintain like this:

    # the declaration puts the message format string and the # class declaration together for the programmer, thus # resulting in less maintenence work declareExceptionClass("Exception::Mine::Copy" , "Could not copy %s to %s", [ qw(from, to) ]); .... some where else in your code ... # there is no need to explicitly call sprintf or # repetitively type variable names, nor even remember # the order of parameters in the format string or check # for undefined values. Both of these will produce # the same error message: # "Could not copy A.txt to B.txt" die "Exception::Mine:Copy"->new(from =>'A.txt', to=>'B.txt'); die "Exception::Mine:Copy"->new(to =>'B.txt', from=>'A.txt'); # and this will politely fill in 'undef' for the # property you leave out: # "Could not copy A.txt to <undef>" die "Exception::Mine::Copy"->new(from=>'A.txt');
Re^2: RFC: A better name for an exception handling module?
by thargas (Deacon) on Dec 22, 2010 at 19:02 UTC

    @jethro: I agree with you comment about *::Lite.

    <rant>
    However, please don't encourage more meaningless names. Meaningful names is one more plus in favour of CPAN, and lack of them is one of my pet peeves about python's library. Moose is a great set of modules and I use them, but I don't like the name; I am willing to concede that all the good names I can think of are already taken. There's a really nice networking framework in python called: Twisted. I think that's twisted and not helpful. I can find useful modules in CPAN by browsing categories.
    </rant>

      I cannot agree more. "Cool" names are kinda OK for the big things like frameworks, but definitely not single purpose modules. Hpricot anyone? Yet another reason I hated Ruby.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.