>
> > 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 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.
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. 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.
--
http://mail.python.org/mailman/listinfo/python-list
