~ryanlowe/blog: UnsupportedOperationException

UnsupportedOperationException

If you are using an agile-type methodology to implement a Java interface you won't be able to implement all of the required methods at once. But the compiler will complain if you don't have the functions there, so you need stubs. Eclipse leaves nice stubs with TODO comments but the functions return default values (ie. null, 0).
public int compare(Object o1, Object o2) { // TODO Auto-generated method stub return 0; }
This is not such a great thing because you might use a method that's stubbed out inadvertently and mysterious bugs will happen. Here's a tip: In each stubbed method throw UnsupportedOperationException.
public int compare(Object o1, Object o2) { // TODO Auto-generated method stub throw new UnsupportedOperationException("method not implemented"); }
It's a runtime exception which means that Eclipse won't tell you to change the function line to include the exception (and you won't have to - and shouldn't - explicitly catch it either). Then when you try to use the method in your code you'll know that method isn't ready yet.

On Jim's Comments: An exception won't be thrown unless you use the unimplemented method. Having your program crap out is exactly what you want to do.

Now if you put code in the stub to simulate functionality then you'd take the exception out, obviously. But when it's completely unimplemented, you need to know that. Using it is a programming error and that's exactly what runtime exceptions are for.

As well, you can't "pay attention to the TODOs" if you are using a class like a black box or abstraction, which is the whole point of OOP.

Posted at May 08, 2003 at 08:47 PM EST
Last updated May 08, 2003 at 08:47 PM EST

Comments

ummm, I don't like that at all. If you are building something like that, that means that you cannot call the stub methods. You just have them in so that it compiles. If you actually hit them your program will crap out.

If you wanted your stub methods to kill the app, I guess you could do a System.exit(0) instead. If you have them returning dummy values, yes, they might go un-noticed if you don't see the todo's, but at least you could test and play with your program.

I think that if you pay attention to the todo's, what they have is fine. If you are building something with a gui, maybe you would want to do a printout message to the console so that you can be reminded of the stubb...

I just don't agree with throwing that exception.

» Posted by: JimboJones at May 8, 2003 09:52 PM

I would have to say that both should be used depending on the problem you're solving.

On one hand, when using exceptions, you are better able to see the flow and dependancy of your methods. This bodes well for solving problems that have many decision points.

However, you can also argue that sometimes you just want to see where you are at in the big picture. That's when it's good just to have your stub print something to the console to remind you harmelessly, but not break the program.

Either one depends on the problem although I believe returning 0, instead of printing something *and* returning 0, is no good. You have to have something to remind you of your incomplete work during compile and runtime, equally.

» Posted by: roy at May 10, 2003 04:30 AM

the unsupported thing is excellent, i use it all the time, the main issue i take with jimbo's comments is that returning dummy values you have to 'pay attention to the todo's'", whereas using the exceptions... the system pays attention for you (also not ryan's comments... just because you throw exceptions does not mean that the code using your stuff has to try/catch it)

» Posted by: andrew at May 11, 2003 02:27 PM