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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
