Project

General

Profile

Actions

Bug #4288

open

Develop GUI error handling strategy.

Added by David Welker over 14 years ago. Updated over 14 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
core
Target version:
Start date:
08/07/2009
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4288

Description

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.


Related issues

Blocked by Kepler - Bug #4286: Changes to the GUI before 2.0ResolvedDavid Welker08/07/2009

Actions
Actions #1

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
be useful.
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.

Actions #2

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 4288

Actions

Also available in: Atom PDF