András Mocsáry 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

On Fri, 2009-12-18 at 13:04 +0100, András Mocsáry wrote:

Hello, I was advised respectfully to post my query here. Please, read the whole letter before you do anything, because I tried to construct the problem step by step. Also keep in mind, that the problem I query here is more general, and similar cases occur elsewhere, not just in this particular example I present below.

Intro story ( Skip if you are in a hurry ) I'm participating in several open-source server development projects, most of them are written in C, and some of them have C++ code hidden here and there. These programs, are developed by many, and by many ways, and so, more often than not it is very hard to determine the 'real cause of bugs'.

This almost always leads to 'bugfixes' which 'treat the crash'. Sometimes they are a few lines of extra checks, like IFs.

Sometimes they are complex, and even surprisingly clever hacks. Thus understanding the 'code' of them is challenging, but the end result is a pile of ... hacks fixing bugs fixing hacks fixing bug, which also were put there to fix yet another bugs. + When I started to learn functional programming, I was told, that the correctness of a functional program can be proved a lot more easily, in fact in a straight mathematical way. + My concern

is about predictable failure of sw written in Haskell. To illustrate it let's see a Haskell pattern matching example:

Let's say I have defined some states my object could be in, and I did in a switch in some C-like language: switch ( x ) { Case 0: "Unchecked" Case 1: "Checked" Case 2: "Unknown" }

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: C-like: switch ( x ) { Case 0: "Unchecked" Case 1: "Checked" Case 2: "Unknown" Default: "Nothing" }

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.

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.

Yes. If program have bug let it be a bug that crash (then you know there is a bug). However in Haskell you have _|_ (read bottom) which indicate that there is an error or exception (returning _|_ is related to throwing excaptions in other languaged).

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.

The first problem is that here int is used as enumeration like if it was assembler. In C the enum is also strongly connected to it's binary representation. But well - it is HL assembler and in some uses it is justified. data State = Unchecked | Checked | Unknown switch Unchecked = "Unchecked" switch Checked = "Checked" switch Unknown = "Unknown" Here compiler knows all possible inputs (Unchecked/Checked/Unknown) and hence it can see nothing else is possible. If there is case not covered it will produce warning. Other module cannot run (switch 4) because 4 is not State. If there is problem with user input you will know it in code which parse user input (i.e. one which will convert 3 into Unknwn).

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.

3. This 'x' could have been corrupted over a network, or by 'mingling' or by other faulty software or something.

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.

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.)

This is very much like warning suppression, just that it's crash suppression, with the need of a report message of course.

I would like to hear your opinion on this.

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.

Thanks for your time reading my 'storm'.

Greets,

Andrew

AFAIU you you ask about having: someFunction :: TypeA -> TypeB someFunction A = ... transformed into: someFunction :: TypeA -> TypeB someFunction A = ... someFunction B = someValue but someValue would have to be of type forall a. a. It should work even for: {-# LANGUAGE EmptyDataDecls #-} data Void well - as far as I know there is only _|_ which fullfill it. Nothing else belongs to for example Void. Other methods of dealing is to use Maybe: switch 1 = Just "Checked" switch 2 = Just "Unchecked" switch 3 = Just "Unknown" switch _ = Nothing Then operating with Maybe monad you can test it using maybe function (returning error): main = do i <- getIntFromSomewhere let s = switch i maybe (hPutStrLn stderr "Incorrect value") putStrLn s Other method, if more complex cases are needed, is using Either or ErrorT monad. In any case you *need* to tell what to do. Should error be printed into stderr? Or maybe send HTML which says input was incorrect? Inform NSA? Give full access? Personally I'd prefere to have: processPacket = readPacketFromInput >>= \i -> case parsePacket i of Just typeSafeData -> doSomething typeSafeData Nothing -> returnErrorToUser Where typeSafeData have type guarantee to be corrected (please remember - in haskell type can guarantee for example that tree is 2-3 B-tree [have equal hight etc.]). Regards