Re: How to name Exceptions that aren't Errors

[Steve Holden]

Leo Breebaart wrote:
I've recently become rather fond of using Exceptions in Python to
signal special conditions that aren't errors, but which I feel
are better communicated up the call stack via the exception
mechanism than via e.g. return values.
Absolutely.
For instance, I'm thinking of methods such as:
    def run(self):
    """ Feed the input file to the simulator. """
        for linenr, line in enumerate(self.infile):
            try:
                current_values = self.parse_line(linenr, line)
==>         except CommentLineException:
                continue
            results = self.do_one_simulation_step(current_values)
            self.process_simulation_results(results)
which I use in order to discard comments from a file I'm parsing
line-by-line.
This specific example assumes that it isn't possible to easily determine 
by examination that the line is a comment, otherwise it's more readably 
re-cast as

        for linenr, line in enumerate(self.infile):
            if not isComment(line):
                current_values = self.parse_line(linenr, line)
                results = self.do_one_simulation_step(current_values)
                self.process_simulation_results(results)
but the general point is still a valid one, so I'll assume you just 
grabbed something that was readily to hand.

My question is twofold. First, I know that many programmers are
violently opposed to using exceptions in this fashion, i.e. for
anything other than, well, exceptional circumstances. But am I
correct in thinking that in Python this usage is actually
considered quite normal, and not frowned upon? Is my snippet
above indeed sufficiently Pythonic?
Well, you will doubtless get as many opinions as you consult 
programmers, but in general there's much more tolerance in the Python 
world for such programming methods, and indeed much more tolerance 
generally than in some communities I've been a part of.

Second, purely as a question of aesthetics, I was wondering if
the folks here might have any opinions about actual naming
conventions for the exception classes used in this fashion.
'CommentLineError' would clearly be wrong, but using the
'Exception' prefix seems a bit redundant and pointless too. I
suppose I could just call the exception "CommentLine" and leave
it at that, but I don't know, maybe there's something better I'm
overlooking.
Here you could be guided by the standard hierarchy, quoted here from the 
2.4 documentation:

    Exception
     +-- SystemExit
     +-- StopIteration
     +-- StandardError
     |    +-- KeyboardInterrupt
     |    +-- ImportError
     |    +-- EnvironmentError
     |    |    +-- IOError
     |    |    +-- OSError
     |    |         +-- WindowsError
     |    +-- EOFError
     |    +-- RuntimeError
     |    |    +-- NotImplementedError
     |    +-- NameError
     |    |    +-- UnboundLocalError
     |    +-- AttributeError
     |    +-- SyntaxError
     |    |    +-- IndentationError
     |    |         +-- TabError
     |    +-- TypeError
     |    +-- AssertionError
     |    +-- LookupError
     |    |    +-- IndexError
     |    |    +-- KeyError
     |    +-- ArithmeticError
     |    |    +-- OverflowError
     |    |    +-- ZeroDivisionError
     |    |    +-- FloatingPointError
     |    +-- ValueError
     |    |    +-- UnicodeError
     |    |        +-- UnicodeEncodeError
     |    |        +-- UnicodeDecodeError
     |    |        +-- UnicodeTranslateError
     |    +-- ReferenceError
     |    +-- SystemError
     |    +-- MemoryError
     +---Warning
          +-- UserWarning
          +-- DeprecationWarning
          +-- PendingDeprecationWarning
          +-- SyntaxWarning
          +-- OverflowWarning (not generated in 2.4; won't exist in 2.5)
          +-- RuntimeWarning
          +-- FutureWarning
Any suggestions?
Obviously *Error and *Warning predominate, but I would suggest it's 
largely a matter of code readability. I've even used an exception called 
Continue to overcome an irksome restriction in the language (you used 
not to be able to continue a loop from an except clause).

As long as the intent of the code is obvious to the casual reader I 
suspect it's very unlikely you'll get complaints.

    except CommentLine:
        pass
seems reasonably comprehensible, so time spent arguing about it would be 
better devoted to a discussion of the number of angels that could dance 
on the head of a pin.

regards
 Steve
--
Steve Holden        +1 703 861 4237  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list