On Mon, 3 Nov 2008, Svein Ove Aas wrote:
On Mon, Nov 3, 2008 at 4:55 PM, Henning Thielemann
I think it is a good idea to switch this feature on and off by a compiler
switch. It does not alter the correctness of a program. If the program is
incorrect, the switch does only affect the way how the program goes wrong.
I disagree.
In a normal program, you may want to mix the two - use the safe
functions for untrusted input, the unsafe ones once you have already
validated the input.
Such a switch, if it existed, should only affect the *unsafe* version
of the call - this way, it would be possible to remove all chance of
corruption from a program at need.
Also, of course, the exceptions should be catchable based on the new
ghc 6.10 exception library (on ghc 6.10, anyhow)
I think you mix up errors and exceptions:
http://www.haskell.org/haskellwiki/Exception
http://www.haskell.org/haskellwiki/Error
If you read untrusted data and encounter an index out of range, then you
must throw an exception (or return an "exception code"). The internal
array bound checking must be active though, since your code that checks
the untrusted data may be buggy. The internal array bound checking is
entirely intended for revealing buggy code, not for validating untrusted
data. That is, for debugging you turn the bound checking on and if you are
sure it is exhaustively tested, then you can turn it off for maximum
efficiency.
You may want to give
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/explicit-exception
a try.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
