[Tutor] Error frameworks

[Kent Johnson]

(Please reply to the tutor list, not to me privately)

DS wrote:
> Thanks for looking at my problem.  Let me try to explain what bothers me
> about raising an error:
> 
> Below is a brain-dead example of one function calling another which
> calls another.  If in function3 I raise an error, function2 properly
> catches an error, but function1 doesn't have a clue what went wrong. 
> However, if I want to have function provide the notification and/or
> handling of the error messages back to the user, then I must have a
> means of propagating that error back up the line.  In this example,
> since the error is given back as a string rather than a numeric, it
> still shows an error, but for general purposes this seems like a bad
> approach.  I've thought of having a tuple returned (answer, error) which
> would carry the message back to function 1, but that seems awkward as well.

Generally, you want to catch the exception at the level that knows what to do about it. Your function2() isn't handling the exception in any meaningful sense, it is just converting it to a magic return value. You might as well just use magic return values everywhere if you do this.

Even function1() seems like it is too low-level to handle the error since it is also just converting the error to a magic return.

For short, simple scripts you can often omit exception handling completely. Any raised exceptions will propagate to the interpreter which will print a stack trace and exit. This is very handy - you get to see exactly where the error occured and the details of the exception type and message. This style may also be appropriate for handling any fatal error even in a complex script.

For more complex scripts, for example a server or GUI app, or a script that processes many items, you probably don't want to exit the script on an error. In this case you might have a high-level exception handler that logs the exception and continues. For example here is a loop that processes a list of items, if there is an error processing an item a traceback is printed and the processing continues:

import traceback
def processLotsOfStuff(listOfStuff):
  for item in listOfStuff:
    try:
      processOneItem(item)
    except:
      print 'Error processing item', item
      traceback.print_exc()

Kent

> 
> Thanks for your help.
> 
> ds
> 
> *def* function1(value):
> 
>     /#   to simply this just calls the next function/
> 	*try*:
> 		value1 = function2(value)
> 		value1 += 1
> 	*except*:
> 		value1 = 'but what is the error?'
> 		
> 	*return* value1
> 
> *def* function2(value):
>     /#   to simply this just calls the next function/
> 	*try*:
> 		value2 = function3(value)
> 	*except*:
> 		value2 = 'error'
> 
> 	*return* value2
> 
> *def* function3(value):
>     /#   let's say real work is performed here/
> 	/#	the input has to be real number, for example/
> 	
> 	*if* value < 0:
> 		*raise* "this is bad, very bad"
> 	*else*:
> 		*return* value + 1
> 
> 
> 
> Kent Johnson wrote:
> 
> 
>>DS wrote:
>> 
>>
>>
>>>Hi
>>>
>>>Is there any particular standard or approach that I should use for an
>>>error framework?  For example, suppose I have a set of functions that
>>>call one another, and an error is triggered.  I want an error message to
>>>be passed back to the user, so I could:
>>>   
>>>
>>
>>Raise an exception, either a built-in if one is appropriate, or one that you define.
>>http://docs.python.org/tut/node10.html tells you how
>>http://docs.python.org/lib/module-exceptions.html lists the built-in exceptions and what they mean
>>
>> 
>>
>>
>>>    1. have an error message passed back to each called function until
>>>it bubbles up to a point to be passed back to the user in some
>>>meaningful way.
>>>
>>>    2. have a singleton error object updated.
>>>   
>>>
>>
>>Both these approaches have several drawbacks:
>>- Errors are easy to ignore or forget to handle
>>- Client code gets cluttered up with error-handling code
>>
>>Kent
>> 
>>
>>
>>>    3.  ??
>>>
>>>What do most people use?  Is there any url that you could point me to
>>>that would help educate me on this point?
>>>
>>>Thanks
>>>
>>>ds
>>>
>>>
>>>_______________________________________________
>>>Tutor maillist  -  Tutor at python.org
>>>http://mail.python.org/mailman/listinfo/tutor
>>>
>>>
>>>   
>>>
>>
>>_______________________________________________
>>Tutor maillist  -  Tutor at python.org
>>http://mail.python.org/mailman/listinfo/tutor
>> 
>>
> 
> 
> 
>