[Haskell-cafe] Pattern matching, and bugs
Jochem Berndsen
jochem at functor.nl
Fri Dec 18 07:20:09 EST 2009
András Mocsáry wrote:
> *My concern*
> is about predictable failure of sw written in Haskell.
> To illustrate it let's see a Haskell pattern matching example:
> And in Haskell pattern matching:
>
> switch 1 = "Unchecked"
>
> switch 2 = "Checked"
>
> switch 3 = "Unknown"
>
>
> Let's say, these are clearly defined states of some objects.
> Then let's say something unexpected happens: x gets something else than 0 1
> 2.
> Now we have a problem, which is most generally fixed in these ways:
>
> 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.
Agreed. The real cause of the problem is that the programmer didn't
prove that x is in {1,2,3} when calling switch.
> Below are some cases x can go wrong:
> *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.*
> *
> Which makes it harder to fix later, and thus eventually means the death of
> the software product. Eventually someone has to rewrite it.
> Which is economically bad for the company, since rewriting implies increased
> costs.
Yes.
> 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.
You should not assume that your input is correct in fault-tolerant programs.
> 3. This 'x' could have been corrupted over a network, or by 'mingling' or by
> other faulty software or something.
Unlikely. There is nothing you can do about this, though.
> Point 1:
> If we allow ourself such general bugfixes, we eventually kill the ability of
> the project to 'evolve'.
>
> Point 2:
> Programmers eventually take up such 'arguably bad' habits, thus making
> harder to find such bugs.
>
> Thus it would be wiser to tell my people to never write Default cases, and
> such general pattern matching cases.
It is a better idea to use the type system to prevent this kind of bugs.
In this particular case, it's better to try to have a datatype like
data X = One | Two | Three
> *
> Which leads to the very reason I wrote to you:
>
> I want to propose this for Haskell prime:
>
> I would like to have a way for Haskell, not to crash, when my coders write
> pattern matching without the above mentioned general case.
> Like having the compiler auto-include those general cases for us,
> but when those cases got hit, then* instead of crashing*, it *should **report
> some error* on *stdout *or *stderr*.
> (It would be even nicer if it cold have been traced.)
And, how would it continue?
Suppose that we have the function
head :: [a] -> a
head (x:_) = x
What would you propose that would happen if I call head [] ? Print an
error on stderr, say, but what should it return? Surely it cannot make
an value of type "a" out of thin air?
Nowadays, head [] crashes the program, and you get an error message to
standard error.
> This is very much like warning suppression, just that it's crash
> suppression, with the need of a report message of course.
This is already possible with exception handling.
> *I would like to hear your opinion on this.*
I don't think it can be implemented in a sane way, or that it's a good
idea to suppress this silently, when an explicit solution already exists.
> I also think, that there are many similar cases in haskell, where not
> crashing, just error reporting would be way more beneficial.
> 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.
You should validate your data in any case. You may even turn a DoS
attack into a "real" security problem with your "solution".
Cheers, Jochem
--
Jochem Berndsen | jochem at functor.nl | jochem@牛在田里.com
More information about the Haskell-Cafe
mailing list