[Haskell-cafe] Pattern matching, and bugs

[Ketil Malde]

András Mocsáry <amocsy at gmail.com> writes:

> 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