On 23/10/2010 12:09 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> Incidentally, this is the general theme with Haskell. Other languages
>> signal an error by returning a null pointer, or if the result is
>> supposed to be an integer, returning a zero or a negative or something.
>> Haskell style is to use ADTs to return something more high-level. This
>> way, the possibility of failure is explicitly signalled in the type
>> system, and the type system will complain if you fail to explicitly
>> check for failure.
>
>    Actually in other languages what is often used for that precise purpose
> is exception throwing. A function always returns valid values, but in case
> of a fatal error it throws an exception instead (which causes the execution
> of the program to diverge right to the exception handling code). The error
> type is directly thrown as the exception parameter.
>
>    Of course in practice people don't usually use exceptions for expected
> errors, only for severe ones.
>
>    Exceptions are, thus, usually not used as the silver bullet for error
> handling.

Right.

The current Haskell language specification doesn't mention exceptions 
(and nor to any prior versions), although most current Haskell 
implementations provide exception handling. General Haskell style is 
that "expected" things (e.g., doing a dictionary lookup and not finding 
the requested key, running a parser and getting a parse error, etc.) are 
handled as ADTs. Unexpected things throw exceptions. That's things like 
I/O errors, "I've run out of memory", "the user pressed Ctrl+C", and so on.

(One mildly unusual one is that terminating a thread is done by throwing 
an exception in that thread - which means you could, in theory, catch 
the exception and make the thread not terminate. Don't do that.)

In fact, the GHC exceptions implementation recently changed, which broke 
a few people's programs. It used to be that all possible exception types 
were hard-coded into the system. If you wanted to throw a user 
exception, you'd have to just throw an "OtherError" exception with a 
descrptive string. Which works, but doesn't make *catching* exceptions a 
lot of fun. The new implementation allows you to define new exception 
types, which are related in a kind of hierachy.

(The hierachy means you can do things like "catch all I/O exceptions but 
ignore any other kind of exception". However, while OO languages like 
Java use the class hierachy to define exception type relationships, in 
Haskell you have to be a bit more crafty...)

>> Maybe they were worried that you could make a reference point to
>> something dynamic, and then free that something, leaving a dangling
>> reference?
>
>    You can do that with current C++ references, so that's not the problem.

Mmm, OK. Was just a thought...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message