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."

Fulvi

Why would you do such a thing? Just add a null check. And if you really want to do something like this do it with boolean flag. Returning Exception seems to be bad idea unless you really have such a requirement. – Quipu

@AniketThakur Please read the full question/post. Yes, I really do have such a requirement, or I wouldn't be posting the question. – Fulvi

if you are trying to return an exception, use throws and have the calling method catch the exception – May

@May Again, please fully read the post. I cannot use Throws in this situation. – Fulvi

Perhaps a cleaner way is to have a custom return type that encapsulates an ErrorFlag as a boolean data member, and optionally the Exception Type and Message as string data members, and return that custom type? – Brewmaster

I would rather work around ESQL's limitations by using an unchecked (AKA Runtime) exception then. – Zaragoza

I would do something like: if (String.IsNullOrWhiteSpace(inString)) throw new ArgumentNullException("inString"); – Tightrope

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?

Delilahdelimit

BIP2917 is a recoverbale exception too so it ought to behave jsut like any other exception at runtime – Delilahdelimit

It's about both, since the java method needs to adjust due to the restrictions the ESQL is forcing upon it. Please see my update for more info. I would like to see the ESQL you used to call that method, as it may be of use for an argument against the dev handling that side. – Fulvi

CREATE FUNCTION callHello() LANGUAGE JAVA EXTERNAL NAME "com.ibm.broker.testing.Hello.SayHello"; – Delilahdelimit

invoked via CALL callHello(); – Delilahdelimit

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.

Honewort

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.

Nonobjective

Could you please explain it here? A bypass like what you suggest is what I'm looking for, and the preferred solution as it doesn't require any fancy return types. If you could also elaborate on why the invocations in ESQL are made this way other than "for good reason" it would help to better the understanding of the situation. – Fulvi

For more information on this subject check this. grosso modo, its a problem of data-type – Nonobjective

As far as I can tell it actually works with exception declared as thrown but I thought I should expand on what is going on here. ESQL is implemented in C++/C as part of the broker runtime. When you declare an externl procedure the C++ side uses JNI to examine the methods available on the object and find one which is a valid match for the parameter signature. As far as I can tell from the JNI docs there isn't a way to detect the "throws" clause. I would go so far as to suggest that it might be worth raising a PMR to ask if that restriction really does apply or not. – Delilahdelimit

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.

Lil

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.

Whinstone

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,
    }

Confection

Since ENUM isn't supported as an OUT parameter type in an ESQL procedure this amounts to just using an int. – Delilahdelimit