 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2006Inheritance.
Hello, public class MyList extends AbstractList<MyType> { ... public boolean add(MyType objMyType) throws Exception { ... throw new Exception("...") } ... } This is not allowed because the overriden method does not throw an exception. Anyway I can accomplish this? Thanks for any info. Stofdeel a écrit : > Hello, > [quoted text clipped - 11 lines] > This is not allowed because the overriden method does not throw an > exception. Anyway I can accomplish this? I think you can't, it would break the interface contract. The Exception must be catched in the method. > public class MyList extends AbstractList<MyType> > { [quoted text clipped - 9 lines] > This is not allowed because the overriden method does not throw an > exception. Anyway I can accomplish this? Any way you can break inheritance by throwing a checked exception? No, there's not. However, if you back up a bit and ask about your specific problem rather than how you want to solve it, then you might come up with something. In the worst case, you could wrap the exception in an unchecked exception before throwing it. That would be unfortunate, but still workable.  Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Hello, > [quoted text clipped - 11 lines] > This is not allowed because the overriden method does not throw an > exception. Anyway I can accomplish this? (1a) You can throw RuntimeException (and its descendants) and Error (and its descendants), but not Exception. So throw something else. (1b) You can wrap your existing exception in a RuntimeException or an Error. This is "risky" in that it could lead to surprising designs (in that methods are now throwing exceptions they aren't supposed to be throwing). (2) You can modify the super class to throw exception. - Oliver > (2) You can modify the super class to throw exception. Not without major messing with the JDK which I recommend to not do. Cheers robert > Hello, > [quoted text clipped - 13 lines] > > Thanks for any info. 1. Consider whether the condition you want to report is already covered by one of the exceptions that List add can throw: UnsupportedOperationException - if the add method is not supported by this list. ClassCastException - if the class of the specified element prevents it from being added to this list. NullPointerException - if the specified element is null and this list does not support null elements. IllegalArgumentException - if some aspect of this element prevents it from being added to this list. If it is, declare your method to throw the specific exception, rather than Exception. Note that you can extend an exception. For example, if he problem is really an illegal argument, but there is some supplementary data that some callers could use, extend IllegalArgumentException. Callers who know about the extra data will be able to use it. Callers that are just expecting a List will still know it is an illegal argument. 2. Create a new method, with a different name. You can then have it throw anything you like, including Exception (though it is MUCH better to throw a more specific Exception subclass). 3. Create an exception that extends RuntimeException. This is a potentially dangerous move, because it circumvents the compile time checks for exception handling. Patricia Great. Thanks all for the replies. > > Hello, > > [quoted text clipped - 46 lines] > > Patricia [Throwing an exception from a method that overrides a method not declared as throwing that exception] > 3. Create an exception that extends RuntimeException. This is a > potentially dangerous move, because it circumvents the compile time > checks for exception handling. But sometimes necessary. Consider, as an example, an Iterator that returns successive lines from a file. If calling next() results in an IOException reading the file, I don't see any alternative to wrapping it in some sort of RuntimeException and throwing the result. > But sometimes necessary. Consider, as an example, an Iterator that > returns successive lines from a file. If calling next() results in an > IOException reading the file, I don't see any alternative to wrapping it > in some sort of RuntimeException and throwing the result. Alternatively, you could consider the contract inherited from the superclass and conclude that it is not possible to satisfy it with an iteration subject to that mode of failure. (Personally, I think this kind of case illustrates the essential futility of checked exceptions. "We kinda have this contract but, like, you don't have to stick to it if it gets in the way or, you know, you can't be bothered or anything") -- chris >> But sometimes necessary. Consider, as an example, an Iterator that >> returns successive lines from a file. If calling next() results in an [quoted text clipped - 6 lines] > subject to > that mode of failure. Or you rationalize that the file going unreadable after it's been opened cleanly, while you're reading lines from it, is the sort of unanticipated, "I don't know what the hell to do next" problem that unchecked exceptions are for. (It occurs to me that the example is poor for a more important reason. Part of the implicit contract for Iterator is that it's safe to stop iterating at any time. Thus there's no guarantee the file ever gets closed. Oh well.) > [Throwing an exception from a method that overrides a method not declared as > throwing that exception] [quoted text clipped - 6 lines] > reading the file, I don't see any alternative to wrapping it in some sort of > RuntimeException and throwing the result. Just to nitpick, the Iterator could catch the IOException if it ever occurs, and treat it the same as normal end of input. It could in that case comply with its contract for hasNext() by always reading one line ahead. There are certainly cases where throwing a RuntimeException that is not documented by the interface or superclass is the most sensible thing to do. It is rare, however, for that to be the only *possible* thing to do. SignatureJohn Bollinger jobollin@indiana.edu >> [Throwing an exception from a method that overrides a method not declared >> as throwing that exception] [quoted text clipped - 11 lines] > case comply with its contract for hasNext() by always reading one line > ahead. Wrong semantics, though, since returning false from hasNext() implies that it's successfully returned all the lines there are. > > Just to nitpick, the Iterator could catch the IOException if it ever > > occurs, and treat it the same as normal end of input. It could in that [quoted text clipped - 3 lines] > Wrong semantics, though, since returning false from hasNext() implies that > it's successfully returned all the lines there are. But does it ? Is the contract of fully generalized Iterator that hasNext() implies that it has successfully returned all the items, or that it has returned all the items that it sucessfully can ? If your custom iterator included an extra boolean hasError() method (which would be poor design, I think, but not actually /incoherent/), then users could distinguish the two cases. I wonder how much harm it would do (or would risk) if the language design were changed so that subclasses were allowed to throw checked exceptions from overrides of methods which declared that they did not throw them. Your file iterator could throw checked IOExceptions, and client code which "knew" it was using one of your iterators would be obliged to recognise that mode of failure, whereas for client code which only knew that it was using a java.util.Iterator would treat the same exception as unchecked. There's some scope for abuse of course, but the worst-case scenario for such abuse is that all such exceptions are treated as unchecked -- which is exactly the position we are already in... -- chris >> > Just to nitpick, the Iterator could catch the IOException if it ever >> > occurs, and treat it the same as normal end of input. It could in that [quoted text clipped - 9 lines] > implies that it has successfully returned all the items, or that it has > returned all the items that it sucessfully can ? The former, I think, just as I'd expect an I/O error reading a file to throw IOException rather than return EOF. To put it another way, if I had a unti test for this Iterator, and an intermittent disk failure resulted in an unexpected exception, I'd understand why. If it resulted in a smaller number of lines than expected, I'd be very confused. 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.