How does a container wrap EJBException?

[zgapp]

Hi,
I was wondering if somebody can help me with my problem. I have simple stateless EJB with the following code in the business method:
...
try {
//call to databse
}catch (SQLException e) {
throw new EJBException(e.getMessage());
} finally {
...

Call to this EJB occurs in the servlet class where I try to catch this exception:
...
try {
//here goes the call to the stateless EJB
}catch(RemoteException e) {
Throwable t = e.detail;
System.out.println("*****t is "+t);
//continue...
}

As a result I am getting the following:
"*****t is java.io.InvalidClassException: javax.ejb.EJBException; Local class not compa
tible: stream classdesc serialVersionUID=796770993296843510 local class serialVe
rsionUID=-9219910240172116449"

Where InvalidClassException came from? Please help....

[mschoning]

Hi.
My guess is that you have different class paths for your client and for your ejb container. So the client is probably picking up another version (from another jar) of the EJBException class. You can create your own exception class and you will probably be able to throw that exception as they both will have to pick up the same version of the new Exception class. To correct your problem with the EJBException, go hunting! Try to find all the jars that have this class in them and make sure that you load the same jar for the client and the container.

- good, luck Michael

[bman917]

I think EJBExceptions are wrapped in a RemoteException. Any way the properway of handling your SQL exception is the throw the exception in your mehtod. For example:

public void youMehtod(...) throws SQLException
{
//do your SQL thing
}

In this way you can directly catch the SQLException instead of trying to wrap it in some weird EJBException which we don't know very well.

[bman917]

I think EJBExceptions are wrapped in a RemoteException. Any way the properway of handling your SQL exception is the throw the exception in your mehtod. For example:

public void youMehtod(...) throws SQLException
{
//do your SQL thing
}

In this way you can directly catch the SQLException instead of trying to wrap it in some weird EJBException which we don't know very well.

[bman917]

I think EJBExceptions are wrapped in a RemoteException. Any way the properway of handling your SQL exception is the throw the exception in your mehtod. For example:

public void yourMehtod(...) throws SQLException
{
//do your SQL thing
}

In this way you can directly catch the SQLException instead of trying to wrap it in some weird EJBException which we don't know very well.

[bman917]

I don't think the container wraps it all. Any way, the proper way of handling your SQL exception is to throw the exception in your method. For example:

public void yourMehtod(...) throws SQLException
{
//do your SQL thing
}

In this way you can directly catch the SQLException instead of trying to wrap it in some weird EJBException which we don't know very well.

[bman917]

I don't think the container wraps it all. Any way, the proper way of handling your SQL exception is to throw the exception in your method. For example:

public void yourMehtod(...) throws SQLException
{
//do your SQL thing
}

In this way you can directly catch the SQLException instead of trying to wrap it in some weird EJBException which we don't know very well.

[petertje]

I totally disagree: that (the last posts i mean) is not the proper way of handling an SQLException.
An SQLException in your bean means there is something wrong with your system. Either your code is sending incorrect SQL statements, or the database connection is lost or something like that. That is what we call a system exception, not an application exception. Proper handling of a system exception is indeed to throw an EJBException or a subclass. The EJB container is mandated (by the spec) to log these exceptions. At the client side, this is translated to a RemoteException indeed, and that is exactly what you want: it indicates that something is going wrong in the server at system level. Returning SQLExceptions to the client is considered bad style; the client shouldn't have to know anything about sql nor about it's exceptions.

Peter.