András Mocsáry
Now we have a problem, which is most generally fixed in these ways: C-like:
switch ( x )
{
Case 0:
"Unchecked"
Case 1:
"Checked"
Case 2:
"Unknown"
Default:
"Nothing"
}
This is not a fix, this is a workaround for a design bug, namely that x is of a type that allows meaningless data.
Haskell like:
switch 1 = "Unchecked"
switch 2 = "Checked"
switch 3 = "Unknown"
switch x = "Nothing"
These general ways really avoid this particular crash, but does something real bad to the code in my opinion.
Yes. The type of the parameter should be designed so that it only allows the three legal values. Using an integer value when there are only three real options is bad design.
*1. The bad data we got as 'x', could have came from an another part of our very program, which is the REAL CAUSE of the crash, but we successfully hide it.*
2. The bad data we got as 'x', could also could have come form a real word object, we have underestimated, or which changed in the meantime.
I think these two are the same - in case 2, it is the parser that should produce an error. If it may fail, there's a plethora of solutions, for instance, wrapping the result in a Maybe. This will force users of the data to take failure into account.
3. This 'x' could have been corrupted over a network, or by 'mingling' or by other faulty software or something.
I'm not really sure how a Haskell program would react to memory errors or similar. Badly, I expect.
I would like to have a way for Haskell, not to crash, when my coders write pattern matching without the above mentioned general case.
I think this just encourages sloppy programming, and as has been pointed out, you can catch the exception if you think you can deal with it reasonably. GHC warns you if you do incomplete pattern matching, and I think it's a good idea to adhere to the warnings.
In my case for server software, where network corrupted data, ( and data which has been 'tampered with' by some 'good guy' who think he's robin hood if he can 'hack' the server ) is an every day reality.
I like the Erlang approach: let it (the subsystem) crash, catch the exception, report it, and restart. -k -- If I haven't seen further, it is by standing in the footprints of giants