Re: [Gnumed-devel] catching errors in an app

[Richard Terry]

On Thursday 26 January 2006 03:33, Karsten Hilbert wrote:
> On Wed, Jan 25, 2006 at 08:41:19AM +1100, Richard wrote:
> > I guess this is well implemented in gnumed.
>
> Unfortunately not. There was talk about how to improve it
> fairly recently on the list.
>
> > Karsten I wonder if you could point me in a direction.
>
> We got a "top level" exception handler in client/gnumed.py
> which wraps the entire client.
>
> However, wxPython catches exceptions inside it's event
> handler AFAIK and they never propagate beyond that. I am not
> aware of a way to control this. If someone can shed light on
> this issue I'd be glad.
Don't think it is easily possible, I enclose  Robin Dunn's reply to my 
question about this.

I'll look at your examples.

BTW on the error topic, it just took me about 2.5 hours yesterday to import my 
clinical demographic database into postgres. Brought home to me once again 
how critical data input validation is in the first place. Secretaries manage 
to fuck up anything they can, inadvertantly of course. There were probably 
many dozens of field errors within the 6,500 patients attatched to the 
practice, things like statesin the postcode field, apostrophies in states 
field, and worst of all, and I'd love a quick script to fix this if you have 
time, carriage returns in a number of different fields.

This affected the COPY function in postgres quite horribly in that the import 
failed when the field before it had a hidden carriage return(s). It took me a 
while to figure it out, but I"m not smart enough to know how to parse the 
text field to automatically remove them , or if postgres has some mechanism.

The text data exported from access has pipe delimited format, ie

field|field1|||||||field2||||| etc etc some of which can be null.

I don't know what the CR character is (or if it is a combination in Dos 
files), but I'd love a few line python routine which scans through the entire 
file and replaces the CR with a blank space - do in seconds what I took 
manually (via going back to the access db table every time the record 
crashed).

This also raises the question of allowing multi-line text inputs in say the 
street field I guess.

I would wlecome your comments on all this.
==============================

ROBINS REPLY TO MY QUERY:

Richard Terry wrote:
> This is probably more pythonic than wx, however:
> 
> Now that I (sort of) have a functional app (my drug browser), how does one 
go 
> about catching the invetible errors.
> 
> Does one have a global error handler, or does one error trap in every 
> subroutine?
> 
> Any examples/pointers to code etc would be welcomed.

Currently exceptions are not passed through the C++ layers so if you 
want to catch them you need to do it in each event handler or callback.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!
===========================================

>
> OTOH we also have a bit of somewhat generic error handling
> in pycommon/gmBusinessDBObject.py but this only applies to
> its sublcasses.
>
> We also have gmGuiHelpers.gm_show_error() and friends to
> ease notification about errors.
>
> > Do have a global error catching module, or specific error
> > routines for earch subroutine.
>
> Well, each error that can be usefully handled needs to be
> handled where it occurs. Other errors should throw
> exceptions as we agreed. However, it is at times a very hard
> decision which errors can be handled and which cannot be
> handled. It is also sometimes not in the power of the called
> subroutine to even theoretically *have* that knowledge.
>
> Karsten