I heard the observation long ago that the hardest area of programming is
error handling, whether dealing with the deepest levels of the OS or
'simple' end user application input. At some point in development it comes
down to
- imagining what could go wrong
- writing some sort of exception routine
- testing the routine under artificially contrived conditions
The last one is vastly complicated by the prospect that multiple error
conditions might occur in combination. Yikes!
We all write code to handle the expected. How far we go--or have the
ability to go--in managing the unexpected depends on factors ranging from
developer experience to budgetary constraints.
Hmm. I hope airliner development gets unlimited budget. ;-)
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Paul Gilmartin
<[EMAIL PROTECTED]
.COM> To
Sent by: IBM IBM-MAIN@BAMA.UA.EDU
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Problems that occur in
production
08/03/2008 04:28
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
On Sun, 3 Aug 2008 22:43:57 +0000, Ted MacNEIL wrote:
>I think this whole approach is WRONG!
>
>There are a lot of problems that occur in production.
> `
>Rather, hire trained professionals that:
>1. Know how to do their job.
>2. Know how to problem solve.
>3. Employ best practices.
>
>The documentation of everything that could go wrong is a never-ending
task.
>
>I thought I saw it all over the last 27 years.
>But, somebody always comes along with somethin new to prove me wrong.
>
I have seen a myopic approach to validating input, consisting of:
o Test for all the ways the programmer can envision that the
input can be incorrect.
o If none match, then assume the input is correct.
Versus:
o Test for the few constructs the specification permits
as correct input.
o If none match, the input is incorrect.
I've seen extreme cases, such as, validating that a string
is alphameric by:
o Testing that it contains no spaces;
o Testing that it contains no commas;
o Testing that it contains no parentheses; ...
This can produce very explicit diagnostics, such as "ILLEGAL USE
OF PERIOD IN PARAMETER", but if the adversary has the source code
he can readily break it by supplying incorrect input the coder
didn't anticipate.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
