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/