 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / July 2006How to override an abstract method returning an interface type
Ciao, I've this class that implements the interface PreparedStatement public class SCTRDebuggableStatement implements PreparedStatement { .... } but I've not implemented the abstract method ParameterMetaData so defined in PreparedStatement ParameterMetaData getParameterMetaData() throws SQLException; Also ParameterMetaData is an interface, all that I need is to compile a very big project, I'm not interested to these classes but how can I modify SCTRDebuggableStatement to finally see it compile without errors... many thanks if you can help me Antonio D'Ottavio www.etantonio.it/en Hi, > Ciao, > I've this class that implements the interface PreparedStatement [quoted text clipped - 11 lines] > modify SCTRDebuggableStatement to finally see it compile without > errors... To make it compile (without ever using this method), implement it by returning null or better throwing an Exception: ParameterMetaData getParameterMetaData() throws SQLException { throw new RuntimeException("Not yet implemented!"); } Otherwise, you will have to implement it by returning an instance of a class, which implements the interface. (That's if your problem is to understand how to return an instance "of a interface".) BTW: It is never a good idea to "get something compile somehow" without understanding the basic concepts... Ciao, Ingo > Hi, > [quoted text clipped - 20 lines] > throw new RuntimeException("Not yet implemented!"); > } I usually use NotImplementedException() for this purpose. It's in the sun.reflect.generics package, and it's not documented AFAIK, so I'm not sure if that's the intended purpose... I've even customized my Eclipse so that instead of generiting methods like public Object foo() { //TODO: Autogenerated method return null; } it generates code like: public Object foo() { //TODO: Autogenerated method throw new NotImplementedException(); } - Oliver > I usually use NotImplementedException() for this purpose. It's in > the sun.reflect.generics package, and it's not documented AFAIK, so I'm > not sure if that's the intended purpose... Any reason to prefer this to java.lang.UnsupportedOperationException? Dan.  SignatureDaniel Dyer http://www.dandyer.co.uk > > I usually use NotImplementedException() for this purpose. It's in > > the sun.reflect.generics package, and it's not documented AFAIK, so I'm > > not sure if that's the intended purpose... > > Any reason to prefer this to java.lang.UnsupportedOperationException? To me, UOE implies that the specified operation will NEVER be supported (e.g. thrown by UnmodifiableList's .add() method), and there may exists code which tries to catch UOE and handle it somehow (perhaps translating it to a IllegalArgumentException("Please give me a modifiable list next time.")). NIE, instead, implies "It's on my TODO list, but I haven't implemented it yet." I haven't seen any code try to catch NIE. Perhaps it pops up in code which does a lot of reflection stuff (which I haven't seen much of yet). - Oliver >> > I usually use NotImplementedException() for this purpose. It's in >> > the sun.reflect.generics package, and it's not documented AFAIK, so [quoted text clipped - 12 lines] > it pops up in code which does a lot of reflection stuff (which I haven't > seen much of yet). Fair enough, and if it were called NotImplementedYetException I might agree. Regardless, the fact it's in the Sun namespace and that the package names imply some connection with reflection and generics would make we shy away from using it. I wouldn't be concerned about code that catches UnsupportedOperationException. I would hope that is a rare occurrence. I can't imagine a use for it that is not an ugly hack to get around some more fundamental problem. I guess the third way would be to write your own ToDoException and use that. Dan. SignatureDaniel Dyer http://www.dandyer.co.uk >>> > I usually use NotImplementedException() for this purpose. It's >>> in > the sun.reflect.generics package, and it's not documented AFAIK, [quoted text clipped - 30 lines] > --Daniel Dyer > http://www.dandyer.co.uk I've configured my eclipse to do the same as Oliver's does, only I my config for methods, looks like..... throw new RuntimeException("${enclosing_type}.${enclosing_method}() not yet implemented - faked for unit tests"); Which produces... public class DerivedClass extends AbstractbaseClass { protected String getName() { throw new RuntimeException("DerivedClass.getName() not yet implemented - faked for unit tests"); } } > I usually use NotImplementedException() for this purpose. It's in the > sun.reflect.generics package, and it's not documented AFAIK, so I'm not > sure if that's the intended purpose... Instead of this you can use java.lang.UnsupportedOperationException which is doucumented and AFAIK is meant for this purpose. SignatureThomas >> I usually use NotImplementedException() for this purpose. It's in >> the sun.reflect.generics package, and it's not documented AFAIK, so [quoted text clipped - 3 lines] > java.lang.UnsupportedOperationException > which is doucumented and AFAIK is meant for this purpose. Sorry for my double-post. I should have read Daniel Dyer's answer first. SignatureThomas Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.