[Tutor] Error-handling for a large modular program

[Alan Gauld]

"Shrutarshi Basu" <technorapture at gmail.com> wrote

> I'm currently working on a research project where we'll be 
> developing
> a moderately complex piece of software. We're designing with
> extensibility in mind. One of the problems I can see right now is 
> that
> our program can potentially create a large number of very different
> errors, some fatal, some not.

That's not unusual. I have worked on projects with over a  thousand
exception classes (in C++ and Java).

> I've only implemented basic error handling through a
> number of try/except blocks and if/elses.

Thats the best way to proceed but...

> However I feel that the code might become increasingly inelegant
> if I keep adding a try/except for every possible error
> (and breaking up the code to make it be a specific as possible
> about the errors). Is there some more generic,
> high-level approach I could use?

How are you using try/except. One of the big advantages of
try/except is that it does not break up your main code flow.
All the excepts sit outside of that.

If you put your main code in a function that raises the errors
then the error handling can come out to a higher level with

try:
   mainprocessingHere()
except error1: ...
except error2: ...
...
except error999:

You can also make things somewhat more manageable by
designing your error heirarchy carefully to use inheritance
to catch superclass errors then in the handlers using if/else
to determine the solution - seeral subclasses may share
a solution. But to be honest I prefer the explicit

except error1,error2,error3:

approach for that.

> One approach I have thought of is creating a error handler class 
> where
> each class method corresponds to a particular error. An instance of
> this class would be created at the start of the program and each 
> error
> would run a method in the class.

But if you extend your program you have to modify your error
handler class to add a new method and your main code will have
dependencies on the class throughout. And if you reuse the class
in other related projects they will be impacted too. By keeping
each exception class distinct its easy to add new error types
without affecting existing code too much and not affecting other
projects at all.

> error handling code, without cluttering the actual working code.

I'm concerned at the fact you seeem to be "cluttering" the code.
The point of try/except is to keep the main code as uncluttered
as possible. Of course sometimes you want to handle an error
in-flow and an inline try/except of if/else is unavoidable but those
are usually minority cases.

> still need try/catch blocks, but the catches wouldn't be
> anything more than method calls.

They can still be that. Or simpler use vanilla functions. I'm not
a believer in writing classes just as a hold-all for a set of
functions. Thats what Python modules are for! But your functions
should probably aim to handle several related error types.

> Since we have 3-4 people, each working on a
> different part of the program, we could each add to this error 
> handler
> as needed.

Yes, if its a module it can hold the exception classes and
the handler functions. In fact if you want to be fancy you could
put the handler in the exception class but personally I think
thats a bad idea since the handler might be diffrent in other 
projects.
I prefer to keep the handlers and exceptions separate.

> Since this is my first real world application that I'm writing as a
> team, I have no idea how error handling is actually done in large
> applications.

Its not uncommon in large apps for the error handling to be
more than half the code. When new grads or other inexperienced
programmers join a big project for the first time they are often
amazed at how much error code there is. The key is to keep it
together and as far away from the main flow as possible and
that's what try/except gives you.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld