Re: [Gnumed-devel] errors and middleware (was 0.2)

[Ian Haywood]

Sebastian Hilbert wrote:
> On Saturday 24 June 2006 10:57, Ian Haywood wrote:
>> Karsten Hilbert wrote:
>>>  pat = gmPerson.gmCurrentPatient()
>>>  emr = pat.get_emr()
>>>  allergies = emr.get_allergies()
>>>  for allergy in allergies:
>>>    if allergy['substance'] == 'pencilline':
>>>      allergy['definite'] = True
>>>      allergy['narrative'] = allergy['narrative'] + '; lab-confirmed'
>>>      success, data = allergy.save_payload()
>>>      if not success:
>>>        print "an error occurred:", data
>>>        print "what we saw   :", allergy.original_payload()
>>>        print "our changes   :", allergy.modified_payload()
>>>        print "database state:", allergy
>> It's not the API but the highly repetitive surrounding boilerplate
>> that is required.
>> I would like to write smart GUI ancestor classes
>> so all this error boilerplate can be done once
>> for the 90% case where it's the same
>> (pretty much 100% from my perspective, I accept you
>> may have widgets which need to handle errors their own way,
>> offhand I can't think what these use-cases are)
>> I can work out how to do it with exceptions, but not
>> with the current API.
>>
>> It's possible to write a wrapper function which takes a middleware
>> result tuple and results either the real data or an exception (having done
>> the user interaction) but this breaks the no-exceptions rule and raises the
>> question (if you're going to let me break it) of why we don't use
>> exceptions to begin with.
>>
> Is it possible to explain the whole matter so I can understand it ? I don't 
> get the problem unfortunately bu would like to understand it.
> 
> Are you guys talking about a generic vs. specific approach ? I mean that 
> right 
> now the code handles errors and the intended work in a way that it covers a 
> lot of corner cases and hides errors from the user where as Ian proposes to 
> just do it (what  ever that means) . 
There are two points.
Currently all errors must be handled at every point in the stack. however
a lot of the time errors are generated at the top (in the database layer)
and handled right at the bottom (in GUI code), with exceptions they can pass
through easily and leave the intervening code uncluttered.

Exceptions also make it easier to have common error-handling code in the GUI 
layer.
IMHO we should do something like this.

    def error (self):
        """
        Handle the current exception
        """
        exc_class, exc = sys.exc_info ()[:2]
        if issubclass (exc_class, GnuMedError):
            title = exc.title
            s = exc.text
        elif issubclass (exc_class, dbapi.OperationalError):
            title = "Database Problem"
            s = str(exc)
        else:
            title = "General Error"
            s = str(exc)
        gmLog.Log (str (exc))
        wx.MessageBox (s, title, style=wx.OK)

then every GUI event handler has simply.

try:

except:
   self.error ()


And that's it for the 99.99% case where e stop what we're doing and report to 
the user,
you can always catch those errors with another try..except further up the stack
where you need to do something special.

Ian