On Thu, May 19, 2005 at 07:32:04AM +0200, Noel Grandin wrote:
> Hi
> 
> My basic suggestion is either
> 
> (a) don't do anything. If an exception happens you have already have a 
> problem. A signal being lost is not such a big deal.

That is certainly an option. If the code isn't changed from its current
form this is exactly what happens.

> or
> 
> (b) have a global application exception handler, which logs the message 
> and perhaps asks the user if the problem is serious enough to abort.
> then do
> 
>               try:
>                       self.sendMessage('thickness_changed', _ot)
>               except:
>                       global_ex_handler.log()
>               try:
>                       self.modified()
>               except:
>                       global_ex_handler.log()
> 
> And I would probably put all of that into a utility method that all of 
> the setters could use.

This idea is a possibility.

Thinking more about the problem of handling exceptions during the
various sendMessage() calls makes me wonder if it is even possible to
solve, or if a solution is possible the cost is complex and expensive,
possibly outweighing the benefits. Many programs simply quit if they
encounter an error like  a memory allocation failure instead of trying
to possibly free up some resources and try the allocation again. Making
the program as robust as possible is what I'm aiming for, so I would
really hope to devise some approach better than an abrupt failure. 

Art


-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822
_______________________________________________
PythonCAD mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pythoncad

Reply via email to