|
 |
Orchid XP v8 <voi### [at] dev null> 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.
> (And then you get to the point where you can perform several
> possibly-failing operations in sequence, and have the sequence
> automatically abort at the first failure, whichout having to write a
> bunch of failure-checking code for each and every failure. It's almost
> like an exception, except that it's regular program data, rather than a
> special "magical" flow control construct...)
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. (For example, failing to open a file because
it doesn't exist is usually not considered a severe error, but a completely
normal situation, in which case you seldom throw an exception. However,
something like running out of memory is such a severe error that it deserves
throwing an exception in most languages.)
Exceptions are, thus, usually not used as the silver bullet for error
handling.
> 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.
--
- Warp
Post a reply to this message
|
|
