Is it good programming to have a return type of Exception?

Question

I ran into an odd situation during a use case on a project: ESQL is calling a java method, sending it a String input parameter which the method will unmarshal, apply some logic, and then store useful info from the unmarshalled object. So, the method must either throw a JAXBException, or use a try catch in order to handle the possible exceptions.

The problem with this is, that ESQL cannot invoke a java method which includes a throws in the signature. BUT, we want any errors to fall through back to the previously calling MBNode so it can be handled appropriately there, so then trycatch is out of the picture.

It struck me that hey, is it not possible to return a type of Exception when we encounter an issue, and null if not? So I wrote a simple method doing so, and though I didn't get any warnings or errors, it seemed just wrong to me in the sense of good programming.

For example:

public Exception doStuffAndCheckForErorrs(String inString)
{
    if(inString.equals(null))
    {
       return new Exception("Your string is null");
    }
    else
    return null;
}

But I just get a terrible feeling about doing anything this way.

I'm open to any thoughts or different solutions to this, especially if there's a way around the ESQL signature issue.

UPDATE:

Adding reference as to why the ESQL procedure cannot call a java method with a throws clause in the signature.

Excerpt from This link under the CREATE PROCEDURE statement section:

"Any Java method that you want to invoke must have the following basic signature: public static (< 0 - N parameters>) where must be in the list of Java IN data types in the table in ESQL to Java data type mapping (excluding the REFERENCE type, which is not permitted as a return value), or the Java void data type. The parameter data types must also be in the ESQL to Java data type mapping table. In addition, the Java method is not allowed to have an exception throws clause in its signature."

Answer 1

This isn't really a question about Java, it's a question about ESQL.

ESQL is able to cope with Java exceptions being thrown through the JNI into ESQL code, you should get a BIP2917 error.

I initially though this might have been an issue with the ESQL method resolver but on IIB v9 I was able to succesfully call the following method:

public static void sayHello() throws Exception{
  System.out.println("hello");
}

This makes me think that perhaps you got something else wrong with your ESQL external function/procedure definition?

Answer 2

The point here is you can't DECLARE an exception will be thrown; you can still throw a RuntimeException - without adding a throws clause.

So if you wrap your JAXBException into a RuntimeException, you can throw it and handle according to your requirements, without breaking either requirement. Not sure if I would do that; I would not like to return an exception-type though as it's not meant to be used as a return code.

Be extra sure that this asynch way of handling the issue won't break the ESQL library, as you'll be bypassing part of their code, possibly leaving part of it hanging.