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