Re: [Gnumed-devel] setCOB()

[Ian Haywood]

On Thu, 11 Mar 2004 19:30:45 +0100
Karsten Hilbert <address@hidden> wrote:

> I am still not having access to the list, have even tried to
> subscribe with another address.
> 
> Anyways, I don't think it is a good idea to decouple error
> handling from the calling code. I am not sure what
> side-effects that might eventually display and also I don't
> think it fits with the workflow. Sitting at the keyboard
> telling the machine to save a record I expect error messages
> immediately after submitting the data without the technical
> possibility to do something else inbetween. IMHO this is not a
> batch process type of work.
Not entirely sure what you mean,
Assuming you mean the use of exceptions generated in the business layer to 
report errors:
        - it *is* immediate: execution goes straight from the "raise" command 
to the error-handling code
        - it is more predictable and less bug-prone than manually testing each 
function's return value.
Testing each function is difficult in this scenario because you end up with a 
massive number of cascading if statements,
exceptions, as I understand it, are just a shorthand for this. I'm not sure 
what we gain by not using them.

OTOH, do you mean using gmDispatcher to report error messages, which I used at 
one point (but checking the code in 
gmPatientHolder now, it does a direct call to gm_show_error). Horst would 
probably favour using the dispatcher, because
it allows configurable reporting (using dialogue box, statusbar, or a visible 
error log (in Richard's client)) 

Having said that, we do need to rework this code, because currently each call 
to gmDemographicRecord gives
rise to a separate SQL transaction: changing a record needs to be a single 
transaction. Perhaps we need to cache the 
changes then have a single call to flushChanges () or similar at the end (look 
at the address changing code in wxpython/gmDemographics.py
for an example. )

The advantage of this is we only need to test one function for errors, so the 
point above is moot.

Ian

-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgpJ5I6Fo5DEc.pgp
Description: PGP signature