errors vs. exceptions

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Tue Dec 08 1998 - 14:36:04 EST


 Here's another thing that is not critical to this release, but which
I want to bring up.

Many API functions say they return null or raise a specific exception
(not error) if they fail. For instance, Class.forName() says it will
raise a ClassNotFoundException if a class is not found.

In practice, however, Class.forName may raise a NoClassDefFoundError
(in Sun's implementation.) It appears they simply propagate the failure
through, just as we do now. This makes sense, as it gives the user
the greatest possible amount of information.

On the other hand, consider a function such as
ClassLoader.getSystemResourceAsStream:

    Open for reading, a resource of the specified name from the search
    path used to load classes.

    Returns: an input stream for reading the resource, or null if the
        resource could not be found

Again, the wisest course of action seems to be to only return null
if the resource was indeed not found, and raise an error or a run-time
exception when something else went wrong, like the file in which the
resource resides was corrupted.

Having said that, it appears that our current approach of spelling
out what error and exception will be raised (as done in SET_LANG_EXCEPTION)
might not always be what we want. On the other hand, some information,
such as the name of a class that wasn't found, might only be available
at the bottom of the call chain.

        - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:08 EDT