why is it not advisable to make user defined exceptions inherited from RuntimeException

Hi everyone
why is it not advisable to make user defined exceptions inherited from RuntimeException?
why we inherit from Exception to make user defined exception.

why user defined exceptions are always checked???

thanks in advance

RabiDas Sharma wrote:
why is it not advisable to make user defined exceptions inherited from RuntimeException?

Who/What source says it's not advisable to make user defined exceptions inherited from RuntimeExceptions?

RabiDas Sharma wrote:
why we inherit from Exception to make user defined exception.

For various reasons. But the simplest of the case if you want to provide additional information.

RabiDas Sharma wrote:
why user defined exceptions are always checked???

I don't think that is right. IllegalArgumentException could have been a good case of a user defined RuntimeException if the API did not provide it already. In one of my current implementations, I have created a custom RuntimeException called InvalidHeaderException to signal that the header record of the csv file uploaded by the user is not in proper format. And the caller method doesn't have to catch this exception.

Based on Steve's response in your other thread, I should add this. :-)

I handled that InvalidHeaderException in a catch block that would throw a custom checked exception. The good thing was I didn't have to have method calls that would handle or declare the InvalidHeaderException. I would have had to do that if I had my actual method throw a custom checked exception where it originated.

I hope it's not a bad programming practice.
You all will correct me if it is a bad practice, right?

Heena Agarwal wrote:I handled that InvalidHeaderException in a catch block that would throw a custom checked exception. The good thing was I didn't have to have method calls that would handle or declare the InvalidHeaderException. I would have had to do that if I had my actual method throw a custom checked exception where it originated.

But that's not a good reason to throw unchecked exceptions (in fact, probably one of the worst, because it suggests laziness).

Based on your more detailed post here, I would say that your InvalidHeaderException is a prime candidate for a checked exception.

Why? Because it contains aspects that, IMO, are vital when choosing which type to throw:

It's focused.

It indicates a condition that can be recovered from.

It's self-documenting.

Personally, I've always liked the idea of checked Exceptions. Unfortunately, the way they've been implemented in many cases is "lazy". What's the point of a method simply throwing IOException, when it's part of a hierarchy that includes 30 subtypes? Or SQLException, which has 10 (which is arguably nowhere near enough)? If one of those subtypes is FileNotFoundException, then I - as someone who might need to use (or, even worse, modify) your program - need to know that. Unfortunately, most methods that throw them simply throw the most generic one they can find and leave it up to the method docs to clarify.

To me, the best checked exceptions are ones that say explicitly to the reader: "If you run this method, this might happen. It's not the end of the world, but you DO need to deal with it", and in most cases, throwing IOException simply doesn't cut the mustard.

So, I got an IOException: Now what do I do? In order to know that, I need to know why I got it. If it's because I entered a filename wrong, chances are I can recover; but if it's because my disk is full, I probably can't do a darn thing.

Your case (at least from what I can gather) is quite different. Your upload method might find an invalid header, which is very specific and - again, from what you were saying - completely recoverable. The program doesn't have a bug - indeed it's done its job properly - the problem simply can't be dealt with by the method. Furthermore, you can document all the possible reasons that you might get an invalid header in the class.

I hate documentation. With a passion . So anything (within reason) that helps me document my program, I'll do. And, written properly, checked exceptions can do just that. Unchecked ones can't. They have to be explicitly documented in every method that throws them.

About the only other thing I can say on the subject: Either use checked exceptions or don't. If you prefer not to have to write try blocks or throws clauses, have ALL your methods return unchecked exceptions, but don't be "half-baked" about it.

My 2¢, and HIH.

Winston

Agree, Winston. Just because somebody has written methods which throw a generic kind of Exception, the rest of us do not have to follow similar poor practice.

Some of what it says has already been covered in this thread, but this page of the Oracle tutorial about exceptions: Unchecked Exceptions — The Controversy covers the issue quite well.

I had read that part of Oracle docs earlier but a lot of things I read at not so reliable sources over time added some confusion to my understanding. I think I understand the idea now. Before I posted my last response, I had just read the items 57-61 from Effective Java on Exceptions and those chapters helped me understand Steve's response in the other thread better. I was already beginning to feel that my InvalidHeaderException should have been a checked exception.

I think I was also confused because I was not sure whether I should consider my case as a completely recoverable case. An invalid header would complete the current request ( without any further processing ) with an error message the user would get on the UI. The message that the file did not have have a mandatory column in the header record would go on the same screen in which he uploads the file and clicks ok. The clicking of ok triggers the functionality. So yes, the exception causes that particular thread to end but I think it can still be considered a recoverable case. If the user uploads a new file and clicks on ok again, it's a fresh new request.

There were still some whys missing in my understanding and Winston helped putting those pieces together. Yes your 2 cents helped, Winston. I think I should make my exception a checked exception. And any part of my code that invokes the said method should know and prepare before hand for what might happen. That in itself is a good enough reason to make it a checked exception.

I am going to change some parts of my code based on your response and in future I will not have to spend so much time on deciding if I should have my code throw a checked exception or an unchecked one. At least I hope so. Fortunately since I have added throws clause in all my methods that throw RuntimeException also, the impact of the change isn't big.

Thanks all.

Heena Agarwal wrote:Fortunately since I have added throws clause in all my methods that throw RuntimeException also, the impact of the change isn't big.

And I just read Item 62 - 'Document all exceptions thrown by each method' from Effective Java and I realized that the throws clause I had put in my method signature earlier was a bad programming style cause it didn't help the users of my API to distinguish checked exceptions from the unchecked exceptions. Joshua Bloch, in his book Effective Java, states that we must use Javadoc @throws tag to document each unchecked exception but we shouldn't put the throws keyword in the method signature for unchecked exceptions.

Since I earlier mentioned that I had put a throws clause for a RuntimeException in my method signature, I thought it necessary to specify at this point that it's a bad programming style and hence it should be avoided. So now those who have read this thread or those that are going to read this thread ( and those who are as ignorant as me ) will know they shouldn't do it.

If I remember correctly, you document all expected Exceptions in the documentation comments, including unchecked Exceptions, but you declare checked Exceptions in the throws clause.

Heena Agarwal wrote:And I just read Item 62 - 'Document all exceptions thrown by each method' from Effective Java and I realized that the throws clause I had put in my method signature earlier was a bad programming style cause it didn't help the users of my API to distinguish checked exceptions from the unchecked exceptions. Joshua Bloch, in his book Effective Java, states that we must use Javadoc @throws tag to document each unchecked exception but we shouldn't put the throws keyword in the method signature for unchecked exceptions.

Agreed, and I'd also add this one: Don't mask Exceptions.

Consider this:A bit simplistic perhaps, but I hope it illustrates the point: the first two lines are totally redundant.

Without them, the method will still throw NullPointerException (NPE) if s is null, and it will do so immediately (see below), so what's the point of "wrapping" it. Does it make things clearer? I don't think so.
A simple:
@throws NullPointerExcetion if ANY object parameter is null.
(my catch-all doc line for stuff like that)
explains exactly what will happen, and I'd have to put one in for the IAE anyway.

And if you need to do anything else with a String? Call its toString() method. All it does is return this, but it makes darn sure that what was passed isn't null. Not everyone will agree with the advice, but I use it a lot.

A really good tip I was given back in my COBOL days (35+ years ago now) was:
Fail fast; and fail LOUD.
and I think it's just as applicable now as it was then. NPE's are some of the nastiest exceptions to try and debug because more often than not they are an effect, not a cause; and people forget that they can happen:
"My method takes a String, right?" - Wrong. It takes a String or a null, unless you explicitly prevent it.

So make them a cause and make sure they happen straight away.

HIH

Winston

Campbell Ritchie wrote:If I remember correctly, you document all expected Exceptions in the documentation comments, including unchecked Exceptions, but you declare checked Exceptions in the throws clause.

That and Joshua Bloch adds that for unchecked exception we should make sure we don't add the throws clause. The @throws tags without the matching throws clause should tell the user of the API that the @throws tag is referring to an unchecked exception.

My earlier code had the @throws tag as well as the throws clause for MyRuntimeException.

Thanks again, Winston.

Winston Gutkowski wrote:NPE's are some of the nastiest exceptions to try and debug because more often than not they are an effect, not a cause; and people forget that they can happen:
"My method takes a String, right?" - Wrong. It takes a String or a null, unless you explicitly prevent it.

So make them a cause and make sure they happen straight away.

HIH

Winston

I do the null check ( followed by instanceof test where needed ) explicitly in almost all my methods that take a reference type including String types and wrapper types. Sometimes I think I overdo it cause the method of the API has already handled nulls and hence my check becomes redundant. Then I do the exercise of removing that redundant bit but this way I'm sure I'm not allowing any nulls to creep in where they're not welcome. At least it gives me that peace of mind. I am guilty of throwing an IllegalArgumentException after catching an NPE. But what if we don't do the Exception translation. What if we really wrap the NPE in an IAE so that none of the trace is lost.


So now the caller can use the getCause method to retrieve the relevant information. What would you say if we handled NPEs in the above mentioned way?

Heena Agarwal wrote:I do the null check ( followed by instanceof test where needed ) explicitly in almost all my methods that take a reference type including String types and wrapper types.

And that's fine too. My style just saves my old wrists from CTS.
The main thing is NOT to forget to do it.

So now the caller can use the getCause method to retrieve the relevant information. What would you say if we handled NPEs in the above mentioned way?

Well, my question would be: Why do they have to? Has all this "wrapping" actually made your program any better? I'd say not, but - as with most more complex things in programming - it's a judgement call.

My judgement: My fingers have already been through 35 years, so I'll stick to keeping them ready for the next program. I should also add that I'm still only a competent two-fingered typist.

Winston

I get what you're saying. Also the part that if a method must take a String parameter, null is a valid argument unless the method documentation states that nulls aren't welcome. So wrapping of an NPE in an IAE might not always be justified in some cases for that reason also.

By the way, with the wrapping of NPE in an IAE approach, callers of such an API would save some typing effort by not having to type that extra catch block for the NPE. :-) I just tested that the stack trace contains the trace of the wrapped exception by default, i.e even if we haven't called the e.getCause() method.

Thanks for going through my never ending questions and for taking out time to explain things in detail.

Thanks to the OP for starting this thread cause it really helped me learn some of the basics I sort of always took for granted.

Heena Agarwal wrote:By the way, with the wrapping of NPE in an IAE approach, callers of such an API would save some typing effort by not having to type that extra catch block for the NPE. :-)

Absolutely right. However, I've taken the time to write and document; the least I can expect of a user that thinks they need to write a try...catch block for my unchecked exceptions is to handle them properly.

Winston

Heena Agarwal wrote: . . . I do the null check . . . . explicitly in almost all my methods . . .

Good idea. I still do not think you should be handling NPEs, however. But, why wrap the NPE in an IAE? The two have different intentions (though there is some overlap). Just let the NPE propagate.

Yeah, we don't have a good reason to wrap the NPE in an IAE. Thanks for the correction. I will keep that in mind. Just yesterday, Winston had explained but I forgot too soon.. forgot it while I was responding to his post.

I'm in that phase of learning what is good and unlearning what was stale... :-)