"spir" <[email protected]> wrote
Actually, I have 2 main modules that work together to achieve the
task.
In the first one(A) is defined a set of objects that outline the
creation
of objects which classes & subclasses are in the second module(B).
So far so good. A needs to import B but B does not need to import A.
A third one(C) copes with exceptions -- so it needs to be referenced
in
both other modules.
Again that's OK, both A and B can import C.
But, in order to provide the user meaning- and help-ful information,
I need to access some elements from the module that launched
the exception.
And this is where the design starts to smell bad.
The exceptions should not need to access the raising class,
the raiser should pass information (perhaps the whole object
via self) into the exception. But exceptions are usually fairly dumb
classes - just transporters of information, it's the handlers where
the intelligence should lie. So how is your exception handling
working?
It should be in the place where the exception is caught.
Actually, the whole of it forms a unity and can be put in a single
file
-- but isn't this true for any application?
No, most well designed applications are modular in nature and
chunks can be taken out and reused and other chunks from
other apps inserted without undue disturbance. But that does
require thinking carefully about data flow between modules and
the location of responsibilities for processing that data.
HTH,
--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - [email protected]
http://mail.python.org/mailman/listinfo/tutor
