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.

Answer 3

Returning Exception is "quick and dirty". It can be very powerful and useful but this should be avoid if possible.

The invocation in ESQL are made like this for a good reason i won't explained here but you can bypass it by using RuntimeException that does not appears in the method definition.

Answer 4

A use case that specifies throwing an Exception sounds like it may be poorly written. What is the business or architectural reason for throwing an Exception?

An alternative would be throw a RuntimeException or a custom subclass. That would allow you to leave it out of the method signature.

Again, the use case seems odd.

Answer 5

The straightforward answer to your question is:

No, it isn't good programming to have a return type of Exception. The mechanism is meant to happen when something goes wrong, therefore a return type of Exception means that you want to receive the consequence of something that went wrong.

I understand that you can't throw Exception, so you should handle the case with other approach.

The boolean aproach is fine when you want to check up some work: good = return true, bad= return false.

The encapsulation of values in an Object is meant when you want to grab the results of the work: good = return new YourResultObject(val1, val2, ..., valx), bad = return null.

Answer 6

What you can do is use return codes like C programs used to do to report about their states.

Alternatively you can also create an Enum and return the Enum, both are more flexible than the Boolean approach if you want to differentiate between different types of errors

    public Enum ReturnCodes {
         SUCCESS,
         NULLSTRING,
         ...,
         OTHERERROR,
    }