Generics/Inner Exception Question

[Chris Ebenezer]

I have some code like this:

package somepackage;

public abstract class StateMachine<T> {

protected abstract class FooState extends State {
protected final void stateEnter() throws StateChangeException {
enter();
}

protected void enter() throws StateChangeException {
}

}
protected abstract class State {
abstract void stateEnter() throws StateChangeException;
}

protected class StateChangeException extends Exception {
}
}

The compiler with eclipse seems to handle it fine. The JDK1.5 compiler
spits out the error:

unreported exception somepackage.StateMachine.StateChangeException; must
be caught or declared to be thrown

For the line where 'enter()' is being called in FooState.

I've tried various combinations of qualifiying the exception class (as
StateMachine.StateChangeException) - and can, when this is qualified
everywhere get eclipse and the JDK to compile it.

However, there appears to be no way of then extending a specific non
generic version of this class and overloading 'State' without having
this error reappear at other levels. Qualifying the names at this level
breaks either compiling via the JDK or Eclipse, or both.

E.g:

class BarStateMachine extends StateMachine<Bar> {
public abstract class BarState extends State {

protected BarState() {

}

protected final void stateEnter() throws StateChangeException
{
enter();
}

protected void enter() throws StateMachine.StateChangeException
{
}

protected abstract State methodOne();
}
}

Can't be compiled - no matter what combination of qualification of the
exception name that I try.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Chris Ebenezer uitte de volgende tekst op 03/19/2006 06:49 PM:

I have some code like this:

package somepackage;

public abstract class StateMachine<T> {

protected abstract class FooState extends State {
protected final void stateEnter() throws StateChangeException {
enter();
}

protected void enter() throws StateChangeException {
}

}
protected abstract class State {
abstract void stateEnter() throws StateChangeException;
}

protected class StateChangeException extends Exception {
}
}

The compiler with eclipse seems to handle it fine. The JDK1.5 compiler
spits out the error:

unreported exception somepackage.StateMachine.StateChangeException; must
be caught or declared to be thrown

For the line where 'enter()' is being called in FooState.

I've tried various combinations of qualifiying the exception class (as
StateMachine.StateChangeException) - and can, when this is qualified
everywhere get eclipse and the JDK to compile it.

However, there appears to be no way of then extending a specific non
generic version of this class and overloading 'State' without having
this error reappear at other levels. Qualifying the names at this level
breaks either compiling via the JDK or Eclipse, or both.

E.g:

class BarStateMachine extends StateMachine<Bar> {
public abstract class BarState extends State {

protected BarState() {

}

protected final void stateEnter() throws StateChangeException
{
enter();
}

protected void enter() throws StateMachine.StateChangeException
{
}

protected abstract State methodOne();
}
}

Can't be compiled - no matter what combination of qualification of the
exception name that I try.

You either have to give the fully qualified name, or only the last part.
StateMachine.StateChangeException is neither of both. The compiler
will look for a class called StateChangeException, inside StateMachine.
There seems to be no such class.

H.

--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEHaale+7xMGD3itQRAvCZAJ9mK7aR3m/SUDk/G6pPOlKMbB54RQCeK6Hl
ynHGtFNfdbGVS/Y+BagnPVI=
=RhgA
-----END PGP SIGNATURE-----

 

[Chris Ebenezer]

You either have to give the fully qualified name, or only the last part.
StateMachine.StateChangeException is neither of both. The compiler
will look for a class called StateChangeException, inside StateMachine.
There seems to be no such class.

Sorry - that was midway through an experiment to try and get the thing
to compile. [Incidentally StateMachine.StateChangeException works in the
top level class].

I think though that what I've run into is this bug in the 1.5 JDK:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5086027

 

[P.Hill]

I have some code like this:

package somepackage;

public abstract class StateMachine<T> {

protected abstract class FooState extends State {
protected final void stateEnter() throws StateChangeException {
enter();
}

protected void enter() throws StateChangeException {
}

}
protected abstract class State {
abstract void stateEnter() throws StateChangeException;
}

protected class StateChangeException extends Exception {
}
}

Chris,

My guess is that you are over using the idea of inner classes
and generics, maybe confusing the two. This collection of stuff looks
like a great set of stuff for a package.

For example, did you really intend these inner classes all to contain
references to the outer StateMachine? That is the result of not using
static on the class definitions.

Why are State and StateChangeException nested in StateMachine, you
show nothing that uses StateMachine, but I could envision where
it MIGHT be useful. What is the design goal here?

Abstract Generic? That sounds overly general to me?

Why is FooState generic? It implements the abstract method listed?

unreported exception somepackage.StateMachine.StateChangeException; must
be caught or declared to be thrown

For the line where 'enter()' is being called in FooState.

But it doesn't say it has never heard of StateChangeException, it just
says it is not properly thrown.

However, there appears to be no way of then extending a specific non
generic version of this class and overloading 'State' without having
this error reappear at other levels.

Overloading is not something you do when subclass State, as in FooState.
What method where you trying to overload?

-Paul

 

[Chris Ebenezer]

My guess is that you are over using the idea of inner classes
and generics, maybe confusing the two. This collection of stuff looks
like a great set of stuff for a package.

To an extent it uses the generic class as a containing namespace yes.
The goal was to create a generic state machine that could be used to
create state machines where the type of the object used to shift state
could be varied, and at the same time avoid exposing genericness beyond
declaration of the state machine itself. For simplicity sake it's nicer
to have the StateMachine methods take and return instances of Foo,

For example, did you really intend these inner classes all to contain
references to the outer StateMachine? That is the result of not using
static on the class definitions.

Yes, some of the enclosed states access members variables of StateMachine.

Abstract Generic? That sounds overly general to me?

Why is FooState generic? It implements the abstract method listed?

Yes. The code is elidded and FooState in this case implements some
abstract methods that have an impact on state machine strategy.

But it doesn't say it has never heard of StateChangeException, it just
says it is not properly thrown.

Sure, but there appears to be no way of referring to this exception from
the extending class. As it happens, the exception being declared as an
inner class as a generic class makes the exception itself generic - and
the compile errors gotten are compile order dependent - this is a javac
bug (see previous post).

 

[P.Hill]

Sure, but there appears to be no way of referring to this exception from
the extending class.

Then simple, define it outside of the complex generic abstract outer,
particularly since it doesn't become subclassed or is generic, it is the
same class for every use of the complex abstract nested generic state
machine.

As it happens, the exception being declared as an
inner class as a generic class makes the exception itself generic - and
the compile errors gotten are compile order dependent - this is a javac
bug (see previous post).

Sounds like the solution is: if it hurts don't do it.

-Paul