Re: Why does Java require the throws clause? Good or bad language design? (fwd)

Arthur J. O'Dwyer <ajonospam@andrew.cmu.edu> wrote:


Yes, I can comment. The scenario is ugly to handle in Java.


The best that can be done is to wrap exceptions from the callback
function in some exception class designed for that purpose, and then let
catcher handle unpacking the original exception and rethrowing it. The
result looks something like this:

    public class CallbackException extends Exception
    {
        CallbackException(Throwable e) { super(e); }
    }

    public interface Callback
    {
        public void run(int arg) throws CallbackException;
    }

    public class CallbackImpl implements Callback
    {
        public void run(int x) throws CallbackException
        {
            if (x == "42") throw new RandomException();
        }
    }

    public void higherLevel(Callback cbf, int[] arr)
        throws CallbackException
    {
        ...
    }

    public void catcher()
    {
        try
        {
            higherLevel(new CallbackImpl(),
                        new int[] { 1, 2, 3, 42, 5 });
        }
        catch (CallbackException e)
        {
            if (e.getCause() instanceof RandomException)
            {
                ... handle exception ...
            }
        }
    }


I agree that it is good design, but it is not handled well in Java.
That is one of the possible improvements I mentioned elsethread.


I'm not part of the c.l.misc crowd, but here goes.

The right way to do it, if you want static validation, is obviously as
follows: you type higherLevel as being a function that, given an
exception list, takes as parameters a function which throws that
exception list, and an array, and itself throws the same exception list.
Abusing Haskell syntax for the moment, the type might be something like:

    (Int -> MightFail e ()) -> [Int] -> MightFail e ()

That is, when attempting to type higherLevel, the exception list (e)
ought to be transparently passed through from the first parameter. The
higherLevel function would automatically pick up the exception type from
its first parameter.

Continuing along the Haskell direction, it's not difficult to build a
Monad in Haskell to handle the problem exactly as given above. The
monad declaration for MightFail looks something like:

    data MightFail e a = Failed e | Success a deriving Show

    instance Monad (MightFail e) where
      (Success x) >>= k = k x
      (Failed y) >>= _ = Failed y

      (Success _) >> k = k
      (Failed y) >> _ = Failed y

      return = Success

    throw :: e -> MightFail e a
    throw = Failed

(This is actually creating the exception handling system; so it's
something that could conceivably be built into some other language; it
shouldn't fairly be counted as part of the code versus the C++ code
above.) The declaration of higherLevel looks like this:

    higherLevel :: (Int -> MightFail e ())
                -> [Int]
                -> MightFail e ()

    higherLevel f [] = return ()
    higherLevel f (i:is) = do f i
                              higherLevel f is

Finally, the following code declares a few exception types, and
implements the callback function and catcher.

data Exception = FirstException | SecondException | ThirdException

callbackFunc :: Int -> MightFail Exception ()
callbackFunc 42 = throw SecondException
callbackFunc _ = return ()

catcher :: IO ()
catcher = do let r = higherLevel callbackFunc [1, 2, 3, 42, 5]
             case r of
                 Success _ -> return ()
                 Failed FirstException -> putStrLn "first exception"
                 Failed SecondException -> putStrLn "second exception"
                 Failed ThirdException -> putStrLn "third exception"

Hope that's something like what you wanted to see, 'cause it took me a
while ;). Of course, you asked about functional languages in general.
This is one functional language. In non-pure functional languages,
you'd be likely to have some kind of ad hoc exception system built in,
much like Java or C++ does.

It's also worth pointing out that this code does not actually fail to
compile if you don't handle all possible exceptions; so in a sense, it
misses the originally stated goal. However, most Haskell compilers have
an option to give a warning if you miss something in pattern matching.
It's up to you to turn it on or off.

--
Chris Smith