error analysis/handling/detecting/reporting/preventing/recovery/reproduce/debug

error analysis/handling/detecting/reporting/preventing/recovery/reproduce/debug

[Jef Mangelschots]

I would like to start a discussion thread on the topic of error
handling:

Suppose you have just developed the first draft of your SW which only
handles nominal cases.
Suppose you are about to make the application more robust by going
over your code again and
modify it in order to:
	- analyse
	- detect
	- handle
	- report
	- prevent
	- recover 
	- reproduce
	- debug
errors/anomalies/faults which can be caused by:
	- system failure
	- bad user input
	- programming failures
	- bad design
	- unexpected input data
	- ...


I'm interested in learning about your
tips/tricks/code-samples/strategies/methodologies/views/guidelines/tools/dos/donts
/pitfalls/minefields/techniques/books/papers/... that can help
software engineers in building more robust SW.
These can cover the fases: debug-mode, code-instrumentation,
applications in use by users
for whatever type of application: GUI, commandline,
multi/single-threaded, OO, servers, device drivers, communication, ...

a litle breakdown to get the discussion started:
------------------------------------------------
analysis:    methods to find anomalies by analysing your code,
error-propagation, ...
detection:   choosing function return-values, pre-/post-validation,
..
handling:    error-codes vs exceptions, handling exceptions at low or
high level, just reporting or fixing the problem, maintaing code
integrity
reporting:   messages on screen, in logfiles, sending eventmessages,
..
preventing:  is it possible to prevent errors and if so, how ... 
recovering:  are there any techniques for recovering from errors,...
reproducing: techniques in reproducing reported anomalies for
debug-purposes,...
debugging:   techniques that can help in debugging,...

some topics:
------------
what can go wrong with casting
memory-leaks
bounds
mathematical overflow/underflow
rounding errors
stack problems

Regards
Jef...

Re: error analysis/handling/detecting/reporting/preventing/recovery/reproduce/debug

[Chad R. Meiners]

How many newsgroups did you post this message to?

Re: error analysis/handling/detecting/reporting/preventing/recovery/reproduce/debug

[Marc A. Criley]

Jef Mangelschots wrote:
> 
> I would like to start a discussion thread on the topic of error
> handling:
> 
> Suppose you have just developed the first draft of your SW which only
> handles nominal cases.
> Suppose you are about to make the application more robust by going
> over your code again and
> modify it in order to:
>         - analyse
>         - detect
>         - handle
>         - report
>         - prevent
>         - recover
>         - reproduce
>         - debug
> errors/anomalies/faults which can be caused by:
>         - system failure
>         - bad user input
>         - programming failures
>         - bad design
>         - unexpected input data
>         - ...

If the first draft of your software is designed only to handle nominal
cases, then the only error error/anomaly/fault present is BAD DESIGN. 
Error handling and recovery must be _designed_ into the system, even if
the actually implementation of the off-nominal recovery handling is
stubbed out for the first draft.

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: error analysis/handling/detecting/reporting/preventing/recovery/reproduce/debug

[Jef Mangelschots]

On Sat, 30 Mar 2002 14:37:37 GMT, "Marc A. Criley"
<mcqada95@earthlink.net> wrote:

>If the first draft of your software is designed only to handle nominal
>cases, then the only error error/anomaly/fault present is BAD DESIGN. 
>Error handling and recovery must be _designed_ into the system, even if
>the actually implementation of the off-nominal recovery handling is
>stubbed out for the first draft.
>


I personally agree with you 100%.
Unfortuantely this happens a lot in the real world.

This is the second time I am thrown in a project at the point where
people tell me: We're pretty confident I does what it is supposed to
do in nominal cases but we still have to put in error handling !
Enter: yours truly.

In my previous project, they even deliberately planned it this way.
(it's even stipulated in the Project Management Plan). And this was a
major aerospace company. 


So I tried to fire my question as generally as possible so to look at
error handling from a broad perspective and maybe get a few pointers
on things I haven't realized yet. I can't ask particular questions
about things i don't know about (unfortunately). I'm fairly new to Ada
developing comming from C/C++ development.

I also posted this in other newsgroups because sometimes certain
practises in a particular programming language could prove valuable in
others. 

Regards
Jef