should error class be defined in the class it logically belongs?

[Ben Finney]

Zhang Weiwu <tristan at realss.com> writes:

> 1. by definition only a canine (a dog) can have CanineDistemper, and
> 2. in no case can CanineDistemper be raised without specifying which
> object (canine) is having the problem,
>
> Thus, CanineDistemper is an integral part of Canine class

You haven't supported that claim, and it doesn't follow from the above
premises. It's not that CanineDistemper is integral to Canine, but
merely that CanineDistemper is conceptually related to Canine.

> and one is naturally tempted to defined CanineDistemper inside Canine
> class.

I'd recommend you decline that temptation.

Exception classes should be defined at module level, because it makes
for more readable tracebacks and there's not much to be gained from
defining exception classes inside other classes.

A class is a distinct namespace, and it will be more difficult for users
of your module to make use of CanineDistemper if they have to reach down
into the implementation of Canine in order to get at that exception class.

> Let some experienced OOP guy explain a bit if this line of thinking is
> logical, or impratical. Thanks!

I think it's illogical, because of the way you've laid out your logic;
the conclusion you assert doesn't follow from your premises.

Even if you contrived a different situation where it would be logical, I
think it is almost surely going to be impractical.

-- 
 \        “Of course, everybody says they're for peace. Hitler was for |
  `\      peace. Everybody is for peace. The question is: what kind of |
_o__)                                peace?” —Noam Chomsky, 1984-05-14 |
Ben Finney