Orchid XP v8 wrote:
> Warp wrote:
>>   It's just that with lazy evaluation even if you *do* execute all 
>> possible
>> code paths that doesn't guarantee that their result is actually 
>> calculated.
>> Thus code coverage might not have the same degree of guarantee than with
>> other languages.
> 
> Depends on what you do with the results.

Heh, and I'm in such a hurry to reply that I completely miss one of the 
most important points.

No matter how buggy your Haskell code is, it *cannot* segfault. It 
cannot access initialised or dangling references. It cannot corrupt 
global variables. It cannot be thread-unsafe. It cannot cause other 
unrelated parts of your program to not malfunction. You do not need to 
test for these bugs because they cannot exist in the first place.

(Unfortunately most or all of those guarantees vanish as soon as you 
start performing I/O. This perhaps explains why Haskell programs usually 
contain the tiniest amount of explicit I/O possible...)

So even if some code path wasn't adaquately tested, the worst thing your 
program can do is

A) Give the caller the wrong answer.
B) Throw an exception.
C) Lock up and loop forever.
D) Eat all of your RAM.

Exceptions can be caught and logged if desired. It's possible to 
annotate them to get some idea where they're coming from. You can use 
the GHCi debugger to make it automatically drop you into debug mode when 
an exception is thrown. If your program segfaults, there's not much you 
can do about it. It just says "segmentation fault" and stops, and that's it.

The other problems are the same as you'd have in any other language. 
(And they're roughly has difficult to fix as anywhere else.) Admittedly 
the last two problems are somewhat more common in Haskell than in other 
languages. (E.g., it's quite easy to write a function that *should* work 
for an infinite input, but doesn't due to a subtle oversight on your part.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message