CODEWITHSUNDEEP
javaexception
Jean-François Corbett
Jean-François Corbett

Reputation: 38520

Exception handling when overridden method does not throw any exception

Short form: How do you throw exceptions (or do nice, clean exception handling; or at least dirtily force execution to stop) when the overridden method doesn't throw exceptions?

Context: We have a license for a piece of proprietary software that can be automated using Java "macros". A user-defined macro must be of this form:

public class MyMacro extends SoftwareMacro {
    public void execute() {
        // user code goes here
    }
}

i.e. a class that extents SoftwareMacro and that has a method called execute that overrides the base class' execute. The contents of this overriding execute are what gets... well... executed when the macro is "played".

But the overridden execute method apparently does not throw any exceptions.

execute() in com.mycompany.mypackage.MyMacro cannot implement execute() in 
somesoftware.base.SoftwareMacro
overridden method does not throw java.lang.Exception

Maybe this is naïve, but while developing I usually like to have the appropriate exception type bubble up to the top and force execution to stop, so that I can see them and go on to debug. This is apparently not an option here.

Should I resort to throwing RuntimeException instead? (since RuntimeException does not need to be specified) That feels a bit sloppy, and a "violation in spirit" of the base class method contracy.

P.S. No, I can't change the source code of the overriden execute method.

Upvotes: 2

Views: 5649

Answers (4)

Dave Newton
Dave Newton

Reputation: 160211

"Should" implies there's a right answer, which IMO there isn't do what meets your needs.

If the system can tolerate a runtime exception, and it meets your needs, why not?

Not that you have a choice, since you can't throw a checked exception.

(Checked exceptions seem like a failed experiment to me, although I understand the motivation.)

Upvotes: 1

JB Nizet
JB Nizet

Reputation: 691825

It all depends on what the "Macro player" does if it encounters a runtime exception, and on what you want to happen.

If it doesn't handle it at all, but you don't care, throw a RuntimeException.

If it handles them properly, throw a RuntimeException.

If it doesn't handle them properly, and you don't want it to fail miserably, then catch the exceptions that might happen in your execute method, and handle them as you feel is the best: show an error dialog box, output an error message, log some error in the logs...

Upvotes: 4

jefflunt
jefflunt

Reputation: 33954

So long as the execute code doesn't absorb the exception, it will still throw it if one is encountered. If the kind of exceptions thrown are either RuntimeException or sub-classes of RuntimeException they don't need to be explicitly declared, mostly because the compiler doesn't enforce their declaration since (as the name implies) they only happen at runtime, and cannot necessarily be predicted at compile time.

If, however, the execute method, which you've said you can't modify, absorbs the exception, and doesn't indicate that exception via a log entry, return value, or some kind of RuntimeException I think you're out of luck.

I would agree with Ernest that it appears that the intent is that the execute method do all its own exception handling.

NOTE: Overridden method signatures don't need to match exactly when it comes to the exceptions they throw - just the name, return type, and list & type of variables.

Upvotes: 0

Ernest Friedman-Hill
Ernest Friedman-Hill

Reputation: 81694

Looks like the intent is that each SoftwareMacro do all its own error handling. Use a big try around your whole execute() method if need be, but don't let any exceptions escape. Do whatever cleanup you need to do inside your execute method, and possibly print an error message for the user, if they provide a way to do that.

You should examine all the APIs they provide -- perhaps there's an error reporting facility you're supposed to use.

Upvotes: 4

Related Questions