In a message dated Tue, 15 Oct 2002, Jonathan Scott Duff writes: > People have used the terms "error" and "exception" interchangably in > this disucssion. To me, an "error" is something that stops program > execution while an "exception" may or may not stop execution depending > on what the user decides to do about exceptions.
I'm not familiar with that dichotomy. In the OO languages I'm familiar with, errors fall into two basic classes, compile time and run time. Compile time errors are 'fatal', in the sense that they will prevent the program from ever beginning execution. Runtime errors throw exceptions, which may be caught, and if not caught at the top level of execution, will cause the program to abort (or do whatever else it is supposed to do by default when an error propagates that far). Java (and at least one of the Eiffel runtimes I've used) makes a further division in the runtime category between "exceptions", which must be handled or declared, and "errors", which are conditions like "out of memory" which are so baroque or whose potential for ocurring is so pervasive as to make required handling a ridiculous burden on the programmer. But you still *may* attempt to handle these errors, if you wish--they are still exceptions. For instance, running on a system in which programs can give previously allocated memory back to the operating system, a program might attempt to use a fast but memory-intensive algorithm, but, upon catching the OutOfMemoryError exception, return the memory to the OS and fall back to a slower but less greedy algorithm. Perl obscures things a bit by its free movement between compile- and runtimes, in some sense collapsing the two types of errors into one, or rather making it possible for either to manifest in the guise of the other. For example, a string eval could cause the ordinarily compile-time syntax error, which would generate a runtime exception, or a BEGIN block might try to perform a division by zero, in which case the ordinarily runtime DivByZero exception would be thrown at compile time (and probably cause the program to "never begin execution" in the sense we ordinarily think about it). So the compile-time vs. runtime error distinction goes away, so far as the programmer is concerned. Since I assume that Perl will not require that subroutines declare the exceptions they might throw (but I guess we'll find out in the next Apo!), the dichotomy Java sets up goes away, too. So, I think it is completely reasonable to use "error" and "exception" as interchangeable terms. If there is a difference, it may be merely in point of view. Errors "happen," while exceptions are "thrown" and "caught." > 1/0 could throw an exception, yet continue execution. Somewhere I > expect we should be able to define a policy for what to do in these > situations. > > use Policy DivideByZero => Nan; > use Policy DivideByZero => Inf; > use Policy DivideByZero => DivideByZeroException; > > I'm sure someone else can pick a better syntax than I. I think miko just suggested one, though I'm still digesting it. Trey
