Re: Benefits of Dynamic Typing

Joachim Durchholz <jo@xxxxxxxxxxxxx> writes:

> Maybe I'm dense, but I fail to see the difference between "unexpected
> situations" (failed contracts on internal data) and "really unexpected
> situations" (failed contracts when using underlying infrastructure).
>
> From the perspective of the end user, I mean.

For the end user they are the same. But they are handled differently.

When the former problem is detected, it logs the error using the
generic mechanism of the compiler for gathering errors, possibly
associated with a source location, and the exception is used only
to transfer the control flow.

The latter problem is detected in parts not specific to the compiler,
and the only information about the reason is carried by the exception
itself (and the stack trace).

The distinctive property of these fatal errors is not that they are
bugs in the compiler, but that compilation cannot continue after they
are found. They only happen to almost coincide currently.

[...]
> Either case, the calling software layer doesn't need to propagate
> the detail information of the exception.

I don't understand. Consider the well known function Map which applies
a function to each element of a sequence and gathers results. If some
application fails, the entire Map call fails with the same exception.
Was it expected by Map? It didn't expected any particular exception,
but it did expect that some application might fail. And the exception
is propagated.

Exceptions are useful when the cause of the problem is separated from
the point when it can be handled by some other code. Without exceptions
I would have to have a separate variant of Map which allows the mapped
function to signal that it wishes to abort processing.

>> This is how it worked in Turbo Pascal. I don't like this. It's too
>> easy to fail to check the status often enough, and then the program
>> will unnecessarily attempt to continue despite its I/O being partially
>> redirected to nowhere, failing to notice that there is a problem.
>
> So what? A few unnecessary calls if an unanticipated error situation
> comes up aren't a big issue. It's the normal case that needs to be
> efficient, not the unanticipated one.

It's not just efficiency but performing other interaction with the
world which shouldn't take place after an error. Besides, it would
be applicable only to reading and writing files; what about other
filesystem operations, like renaming a file or listing directory
contents? In these cases there is no file object to store the error
flag in.

--
__("< Marcin Kowalczyk
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/
.

Relevant Pages

  • Re: IllegalArgumentException vs. NullPointerException and collection behavior
    ... There is an advantage to declaring a checked exception - it forces client programmers to pay attention to it. ... The trouble with throwing any RuntimeException is that the API clients might fail abruptly because their programmers didn't pay close enough attention to the Javadocs. ... Throw a checked Exception if the client should have been able to count on getting a result, and you want to force awareness of any out-of-band problems. ...
    (comp.lang.java.help)
  • Re: INVALID_HANDLE_VALUE vs. NULL
    ... 0 (zero) can never be a valid handle value. ... Of course, ReadFilewill fail with this handle, ... > CloseHandle() does indeed fail when given a bad handle. ... > case it raises an exception. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Try..Except fails. Also - any other ways?
    ... case - you see, the file i'm testing on - a log file, is getting logged ... it fail, or if it does fail - for this to be handled. ... Btw - Any ideas why the catch-all exception handling didn't work either ... You will get a 'bad' Handle -1 if FileOpen fails ...
    (comp.lang.pascal.delphi.misc)
  • Re: Benefits of Dynamic Typing
    ... and the only information about the reason is carried by the exception ... Was it expected by Map? ... but it did expect that some application might fail. ... this exception trace is just debugging information and can be ...
    (comp.lang.functional)
  • Re: trouble passing float array from C to java method
    ... running in the background and calling my Java function when it gathers ... After every call to JNI you should check for errors (there are, in fact, a few ... This can fail. ... This can fail by throwing a Java exception. ...
    (comp.lang.java.programmer)