Group:
exception handling
Group:
testing
Topic:
compiler error checking
Topic:
default exception handler
Topic:
dialog boxes in a user interface
Topic:
ease of use
Topic:
error safe systems
Topic:
exceptions and undesired events
Topic:
execution tracing
Topic:
help in UserInterface
Topic:
error checking in robot programming
Topic:
run-time assertions
Topic:
syntax analysis
Topic:
usability errors
| |
Subtopic: fault manager 
| Quote: the fault manager manages the list of problems for human administrators; summarizes the underlying error messages [»shapMW12_2004]
|
Subtopic: error dialog
| Quote: error conditions ought to lead to a permanent message that is terminated only by user action
| | Quote: acceptable user modes are long-term, or short-term "spring-loaded" modes (e.g., scrolling), or alert modes for error recovery [»apple_1987]
| | Quote: modes are acceptable if they emulate real-life (e.g., tool selection), change attributes only, or block most normal operations (alerts) [»apple_1987]
| | Quote: dialog boxes suspend normal operation and can't be moved; the user enters needed information or cancels the operation [»apple_1987]
|
Subtopic: good error messages
| Quote: unambiguous error location, error message about what is wrong; independent of grammar or parser [»richH7_1985]
| | Quote: descriptive assertions near the point of failure [»shorJ9_2004]
| | Quote: an error handling system most avoid inaccurate messages [»kantE7_1986]
| | Quote: error messages should be brief with an option for additional information [»drapSW_1986]
| | Quote: messages to the user should be descriptive of the problem and not evaluative [»heckP8_1982]
|
Subtopic: corrective action
| Quote: the best error message proposes a correction to the error; use only if known [»kantE7_1986]
| | Quote: if an error may have multiple corrections then report each one [»kantE7_1986]
|
Subtopic: message wording
| Quote: error messages should be defensive (blame the system), precise, and constructive [»moliR3_1990]
| | Quote: error messages should reflect system limitations rather than user's inadequacy [»rellN3_1981]
| Quote: error message template: I cannot , because [»efeK11_1987]
| Quote: do not use emotional words in a user interface; e.g., "kill," "abort," and "default" [»tognB_1992]
| |
Subtopic: users cause problems quickly
| Quote: simulated SmartHelp messages had to be generated on the fly since users were too creative and quick in generating errors and misconceptions [»carrJM9_1988]
|
Subtopic: abstraction level
| Quote: a system can generate errors at highest level of intention and let users explore error/history/state to whatever depth desired [»efeK11_1987]
| | Quote: a robust library expresses constraints as types, reports errors relative to user, and does not cause application errors [»fricA4_2000]
| | Quote: an error message is designed for the caller of that operation but not for callers of caller [»efeK11_1987]
| | Quote: low level error messages are inappropriate or vacuous unless the user's intention is known [»efeK11_1987]
|
Subtopic: invocation tree
| Quote: implement error messages as an invocation tree of error messages and callers with the last one returned [»efeK11_1987]
| | Quote: explore invocation tree on error by reporting operation name and error within context of operation [»efeK11_1987]
| | Quote: explore invocation tree with why? to move down tree and then? to show next action [»efeK11_1987]
|
Subtopic: syntax errors
| Quote: handle syntactic errors with a table of erroneous productions; appropriate error message and recovery [»wirtN1_1968]
| | Quote: reports syntax error by underlining all text which was skipped by compiler [»kantE7_1986]
| | Quote: report a syntax error by listing the possible symbols at the error location [»kantE7_1986]
| | Quote: a first order error if only one symbol possible; allows accurate error reporting; if two in a row, reports two close errors [»kantE7_1986]
| | Quote: second order errors allow multiple symbols; must scan to the recovery symbol for that error; algorithm given [»kantE7_1986, OK]
| | Quote: what can be proved about syntactic error recovery without correcting the input text or parser state [»richH7_1985]
|
Subtopic: instant syntax errors
| Quote: Cornell_Program_Synthesizer reports syntactic errors as soon as they are made [»teitT9_1981]
|
Subtopic: mapping error to source
| Quote: using correct traces to identify the cause of multiple, erroneous traces of a model checker [»ballT1_2003]
| | Quote: map a runtime error to a source instruction by recompiling the procedure; used in SOAR and TurboPascal [»sampAD11_1986]
| | Quote: alias burying requires a complex, intraprocedural analysis; minor source-level changes may lead to confusing error messages
|
Subtopic: logging messages
| Quote: keep a running log to recover history of unrecoverable errors [»akscRM9_1984]
| | Quote: list of all corrections to TEX over 10 years [»knutDE7_1989]
|
Subtopic: warnings vs. errors
| Quote: Java seldom uses warning messages; e.g., 'used-before-set' is an error [»goslJ6_1997]
|
Related Topics
Group: exception handling (12 topics, 314 quotes)
Group: testing (18 topics, 557 quotes)
Topic: compiler error checking (16 items)
Topic: default exception handler (3 items)
Topic: dialog boxes in a user interface (15 items)
Topic: ease of use (47 items)
Topic: error safe systems (76 items)
Topic: exceptions and undesired events (29 items)
Topic: execution tracing (42 items)
Topic: help in UserInterface (33 items)
Topic: error checking in robot programming (6 items)
Topic: run-time assertions (25 items)
Topic: syntax analysis (29 items)
Topic: usability errors
(6 items)
|
