Date: Tue, 3 Oct 2000 13:55:03 -0700 (PDT)
From: Yingxian Wang <###@###.###>

Josh and Mark expressed concern about several places in URLConnection throwing
IllegalAccessError, saying that only the VM should throw this error. We all
agree that this is an improper Error to throw (this is in the jdk since the very
beginning), but Jeff expressed his concern that changing this to
IllegalStateException now will break applications. So Maxine asked me to seek
opinions from Steve to find out if it's ok for us to make the change.

From: Jeff Nisewanger <###@###.###>
Having thought about this a bit more since this morning's
meeting, I'm now inclined to say that we should go ahead and fix this.
It is clearly the wrong exception to throw, even when the code was
first written. Most likely, it was used because IllegalStateException
did not exist yet and rather than create a better Exception class this
was thrown because the name "sounded right". This is a subclass of
Error and Error is a Throwable, not an Exception, so very few folks are
probably expecting to catch and handle this. Most current code
would probably barf with an uncaught exception on the thread if one
of these were ever thrown by URLConnection. If we start throwing
a RuntimeException like IllegalStateException instead then more code
is probably likely to handle this "better".

BTW, there is an active bug report on this issue. It is bugid
4082758 -- methods in URLConnection should not be throwing
IllegalAccessError. I've updated the evaluation with my comments.
We also need to apply any fix to a coulpe of Sun http URLConnection
implementation classes.

From: Joshua Bloch <###@###.###>
From: "Steve Wilson" <###@###.###>

> 1. Looking at the docs for URL connection it doesn't specify anywhere that
> IllegalAccessError is ever thrown. The fact that it is ever thrown is
> simply an implementation detail, right?

     Yes, and not one that people are likely to depend on.

> 2.Since IllegalAccessError is an Error (not an exception) it is unchecked.
> IllegalStateException is also unchecked right?

    Yes.

> 3. I don't have the source for this handy (my workspace is totally
> scragged). Which methods in URLConnection currently throw
> IllegalAccessError?

   A whole bunch of them. (I don't have the source handy either.)

        Josh


From: Yingxian Wang <###@###.###>

>I agree IllegalAccessError sounds like the wrong thing to throw, but let me
>ask a couple questions:
>
>1. Looking at the docs for URL connection it doesn't specify anywhere that
>IllegalAccessError is ever thrown. The fact that it is ever thrown is
>simply an implementation detail, right?

Right on both accounts. But I think we should document this. This is also
suggested by Josh and Mark.

>
>2.Since IllegalAccessError is an Error (not an exception) it is unchecked.
>IllegalStateException is also unchecked right?

Right again.

>
>3. I don't have the source for this handy (my workspace is totally
>scragged). Which methods in URLConnection currently throw
>IllegalAccessError?
>

The following methods currently throw IllegalAccessError:

public void setDoInput(boolean doinput);
public void setDoOutput(boolean dooutput);
public void setAllowUserInteraction(boolean allowuserinteraction);
public void setUseCaches(boolean usecaches);
public void setIfModifiedSince(long ifmodifiedsince);
public void setRequestProperty(String key, String value);
public String getRequestProperty(String key);


From: Yingxian Wang <###@###.###>

>With the above methods, the developer has to do something pretty strange to
>get the Error to occur, right? Not many people are ever going to encounter
>it, right?
>

This error can occur if the developer is doing things in the wrong sequence.
Although the correct order is documented, the user can still do the wrong things
and thus get this error. But the proposed substitute is a subclass of
RuntimeException, thus it still doesn't require the user to do anything.

Jeff's comment on this is attached.

Yingxian

From: "Steve Wilson" <###@###.###>
I agree. Go ahead and change it. Please send the details to Alan Sommerer
so he can add this to the compatibility page.