Re: signal handling and (structured) exception handling
Peter wrote:
[..]
Another example is a floating pointexception.
Withexceptionhandling I could avoid having to secure the code
against invalid inputs,
which also slows it down.
Some may disagree but I'd recommend against this line of reasoning. Exceptionhandling is
not a replacement for input validation.
To know exactly which input values are going to result in a NAN or INF
value
is not possible for my code.
It's not "not possible". It *probably* requires more effort than you're
willing to expend. Hardware FP exceptions are produced by some
calculations that usually can be identified and singled out for input
verification. For example, when calculating inverse matrix using the
determinant method, you only need to check the value of the determinant
once to avoid dividing by 0. You could also avoid overflow or underflow
by predicting the result of dividing by a large value or by a small
value. When you're about to calculate a square root, check the value
for negativity (and don't do it if it's negative). And so on. What you
seem to advocate is the use of exceptions (which can be quite expensive)
instead of picking apart your FP expressions to find the subexpressions
that can cause problems and then inserting simple, efficient (trust me,
they usually are) and more explicit checks. Those checks would allow
you to identify the problem to your user with much better detail than
the exceptions would.
Programming languages were created by lazy programmers. Programmers
should be lazy to be more productive (however paradoxical it sounds).
So, to paraphrase Einstein, be as lazy as possible, but not lazier.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask