"Strong typing vs. strong testing"

[Lie Ryan]

On 10/01/10 00:24, TheFlyingDutchman wrote:
> 
>>
>>> If I had to choose between "blow up" or "invalid answer" I would pick
>>> "invalid answer".
>>
>> there are some application domains where neither option would be
>> viewed as a satisfactory error handling strategy. Fly-by-wire, petro-
>> chemicals, nuclear power generation. Hell you'd expect better than
>> this from your phone!
>>
> 
> I wasn't speaking generally, just in the case of which of only two
> choices RG's code should be referred to - "blowing up" or "giving an
> invalid answer".

I can make any application never blows up. Just put this in the main()
of every application you write:

while True:
    try:
        ... program goes here ...
    except:
        pass

Done. Program never halted execution, it never blows up. My program is
bug free, heck why do thousands of computer scientists can't figure out
that such a simple construct will fix all bugs once and for all?

> I think error handling in personal computer and website software has
> improved over the years but there is still some room for improvement
> as you will still get error messages that don't tell you something you
> can relay to tech support more than that an error occurred or that
> some operation can't be performed.

I think the ideal error message tells the user exactly what's wrong and
how to fix the problem. A generic error message like "This program
encountered a problem, and need to close." is as useless as an error
message could be.

> But I worked with programmers doing in-house software who were
> incredibly turned off by exception handling in C++. I thought that
> meant that they preferred to return and check error codes from
> functions as they had done in C, and for some of them it did seem to
> mean that. 

Introduce them to RAII (Resource Acquisition Is Initialization), that's
a superior alternative to exception handling in C++.

> But for others it seemed that they didn't want to
> anticipate errors at all ("that file is always gonna be there!"). I
> read a Java book by Deitel and Deitel and they pointed out what might
> have lead to that attitude - the homework and test solutions in
> college usually didn't require much if any error handling - the
> student could assume files were present, data was all there and in the
> format expected, user input was valid and complete, etc.

Personally, the amount of error message I'd design into the program
depends on the expected level of proficiency of the expected users. If
I'm developing for an in-house software, and most of the users of my
program are expected to be experts or have necessary training, I'd be
less inclined to include sophisticated error checking in favor of
simplicity (but I usually work in high-level language, where errors like
non-existent file will throw an exception instead of passing silently,
so take it with a grain of salt). If I'm designing software for a
general public though, I'd include multitudes of idiot checking.