To throw or not to throw?!

[Bojan Knezovic]

I'm trying to log on to Crystar Enterprise 10 server:

  
IEnterpriseSession entSession = CrystalEnterprise.getSessionMgr().logon("administrator","","APSName","secEnterprise");

The getSessionMgr() method throws SDKException which extends AbsstractException which in turn extends java.lang.Object - not Exception, not even Throwable. Obviously I need to put the above statement in a try/catch block, but if I write something like

catch (SDKException ex)

the compiler is unhappy bacause SDKException is not Throwable and therefore cannot be caught. If I quit the line, it's unhappy again because the method might throw the darned SDKException!

Has anyone seen something like this? How do I solve it?

TIA,
Bojan

[Ernest Friedman-Hill]

Wow, that's weird. That API is simply not legal Java.

I think the best tool for dealing with this would be an email client. Write to the vendor of this POS and ask them what's up.

[John Smith]

The getSessionMgr() method throws SDKException which extends AbsstractException which in turn extends java.lang.Object - not Exception, not even Throwable.

Can you post the vendor's javadoc for the SDKException class and the getSessionMgr() method? I'd love to see something like that.

[Jeroen Wenting]

if it doesn't extend Throwable there's no need for a try-catch block (in fact, it'll never get caught at all).

Indeed get in touch with whoever thought this up and slap them with a VERY large trout.

[Bojan Knezovic]

For the curious ones:


com.crystaldecisions.sdk.exception
Class SDKException
java.lang.Object
|
+--AbstractException
|
+--com.crystaldecisions.sdk.exception.SDKException





com.crystaldecisions.sdk.framework
Class CrystalEnterprise
java.lang.Object
|
+--com.crystaldecisions.sdk.framework.CrystalEnterprise

static ISessionMgr getSessionMgr()
Returns the singleton ISessionMgr object.




The code in question should be something like this:

    // Get a session manager.
    ISessionMgr sessionMgr;
    try
    {
        sessionMgr = CrystalEnterprise.getSessionMgr();
    }
    catch (SDKException e)
    {
        return "<select disabled><option>Authentication types unknown</option><select>";
    }
 

I mean there are a few examples out there (not to mention the documentation that comes with tho product) that have the very same syntax that doesn't work in my workshop. I was wondering if there was a "change" in the near past in the JLS or something that made this impossible...?

Duhhh.... back to the search for another product.


Thanks for the help, guys.

[Jeroen Wenting]

from the JLS (par. 14.17)

The Expression in a throw statement must denote a variable or value of a reference type which is assignable (�5.2) to the type Throwable, or a compile-time error occurs. Moreover, at least one of the following three conditions must be true, or a compile-time error occurs:
The exception is not a checked exception (�11.2)-specifically, one of the following situations is true:
The type of the Expression is the class RuntimeException or a subclass of RuntimeException.
The type of the Expression is the class Error or a subclass of Error.
The throw statement is contained in the try block of a try statement (�14.19) and the type of the Expression is assignable (�5.2) to the type of the parameter of at least one catch clause of the try statement. (In this case we say the thrown value is caught by the try statement.)
The throw statement is contained in a method or constructor declaration and the type of the Expression is assignable (�5.2) to at least one type listed in the throws clause (�8.4.4, �8.8.4) of the declaration.

Chapter 11:

Every exception is represented by an instance of the class Throwable or one of its subclasses; such an object can be used to carry information from the point at which an exception occurs to the handler that catches it. Handlers are established by catch clauses of try statements (�14.19).

14.19

A try statement may have catch clauses (also called exception handlers). A catch clause must have exactly one parameter (which is called an exception parameter); the declared type of the exception parameter must be the class Throwable or a subclass of Throwable, or a compile-time error occurs. The scope of the parameter variable is the Block of the catch clause.

As far as I'm aware that has never been different.
If their product throws things that aren't of type Throwable I can only conclude they compile and run on a non-JLS compliant JVM.

[John Smith]

com.crystaldecisions.sdk.framework
Class CrystalEnterprise
java.lang.Object
|
+--com.crystaldecisions.sdk.framework.CrystalEnterprise

static ISessionMgr getSessionMgr()
Returns the singleton ISessionMgr object.

Well, in this javadoc, there is no mention of any kind of exception thrown from the getSessionMgr() method. Looks like
some people call it as such, outside of the try-catch block, and without declaring the specifying it in the "throws" clause.

Perhaps SDKException is not really an exception in a JLS sense, but rather a misnamed class that has some "exceptional" purpose?

[Bojan Knezovic]

Originally posted by Eugene Kononov:
com.crystaldecisions.sdk.framework
Class CrystalEnterprise
java.lang.Object
|
+--com.crystaldecisions.sdk.framework.CrystalEnterprise

static ISessionMgr getSessionMgr()
Returns the singleton ISessionMgr object.

Well, in this javadoc, there is no mention of any kind of exception thrown from the getSessionMgr() method. Looks like
some people call it as such, outside of the try-catch block, and without declaring the specifying it in the "throws" clause.

Perhaps SDKException is not really an exception in a JLS sense, but rather a misnamed class that has some "exceptional" purpose?

It ocurred to me too, but the BEA Workshop is very clear:

"ERROR: This expression can throw an exception com.crystaldecisions.sdk.exception.SDKException..."


OTOH, there are examples out there with the same piece of code working... that's why I was wondering if there was a change in the JLS or something. Don't get it really.

[Tony Morris]

The getSessionMgr() method throws SDKException which extends AbsstractException which in turn extends java.lang.Object - not Exception, not even Throwable.

The basis for your reasoning is incorrect.
You can't declare to throw something that is not a java.lang.Throwable, since a compile-time error will result.