Develop GUI error handling strategy.
We need to think about how various sorts of errors should be handled. Some should cause immediate failure while others should allow the application to continue.
Updated by Christopher Brooks over 14 years ago
Having some exceptions that cause immediate failure and some that allow
execution to continue is an interesting research topic.
To do this, we could add an exception class called Warning that would be
a runetime exception that could be thrown by an actor if the problem would
not significantly change the output of the actor. Directors could then
have a parameter that controls when they stop execution depending on the
exception. For example, a director could stop execution immediately
when it gets a Warning, or finish the iteration, or finish the entire execution.
Also, actors could produce Nil tokens after receiving certain types of errors.
Lisp has this notion of speed and safety, where each is represented by
a number from 1 to 3. For example, speed=3 and safety=1 means run "run fast,
ignore errors". Having a similar system for the execution engine would
We could apply a similar rating system to Warning exceptions, where exceptions
that have a certain severity would be handled differently. Logging systems
have a similar notion of severity (debug, info, warn etc.)
I'm marking this as an enhancement and honestly think this is a post-rel-2.0
issue. I'll leave changing the target to someone else.