This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Very often nothing special; a constructor that accepts a String message and calls "super(message)" is the most common thing. The most important thing about a custom exception type is just that you get to catch it by class name in its own catch block.
Now, sometimes custom exception types have other members; for example, how about a "TemperatureTooHighException" that had a member to hold the temperature and a "getTemperature()" method to retrieve it. It's extremely rare that you'd see much more than that.
Often you would want a constructor that accepts another Throwable as a nested cause - these can be invaluable for debugging. I usually just copy the same 4 constructors that are used in Throwable, Exception, and Error (as well as many, many others):
I will sometimes omit the first and third in order to, um, strongly encourage the programmer to give a meaningful error message. Sometimes I will omit one of the other two as well if I am certain that either there is always another Throwable cause, or there never is. But this is rare.
Note that if a programmer neglects to provide constructors that set the Throwable cause, it's still possible to do this:
It may be redundant to include e twice like that, but I find it can be helpful to include a short toString() representation of e that will appear on the first line, and then the full stack trace will appear later on. Unfortunately the initCause() trick isn't as well-known as it might be, so it's usually a good idea to include the Throwable-accepting constructors in any exception class, to encourage the possibility that they'll be used when needed.
I made one once that stored the stack trace as a serializable string variable so it could survive the trip between JVMs. We also made our own chain of nested exceptions before the standard ones had such a thing.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: May 28, 2007
Hello there ! You can't possibly imagine how thankful I am for the responses you've given me.! Well, continuing on the present topic, When will it be a good practice to write a custom Exception class?
Thank you very much ! Your Java apprentice friend, Jose
I am talking more on Bsuiness logic side, so I am specifically talking about you following quotes,
" What should regularly go inside a class that extends Exception? in terms of Business logic."
and this is what your actual question is right?
Now when we create custom exception class? as per my experience we create it when any one try to break the business logic/rule, for example suppose we have created api and some one else is using our code and they are not using as per our actual implemented logic so we can throw our custom exception. For example you can consider the example of Ernest above "TemperatureTooHighException" so this is valid excpetion that we can throw, instead of putting if else condition.
Custom Exception is really good, because it helps us to maintain our business rules.
Jose this is how all this work, hope with this you can end up your study of Exception handling.
Regards, Makwana Deepak.
Joined: May 28, 2007
Good day to everyone reading this post! I gotta say, My understanding about Exceptions is now clearer, However I believe I need an example of a method that declares that throws a Custom Exception.... If its not much of a trouble could you please assist me demonstrating How it should be done,
Given this (as posted earlier):
What would go inside a method like this one?
As you may have noticed I think It'd be really helpful for me to see now what would you put in the if(server is down) code. I think that will make me see the Big Picture.
What can I say.. I need a lot of schooling, and I'm so thankful. Sincerely, Jose
author and iconoclast
The specifics depend entirely on how your code finds out there's a problem. Let's start from a simpler case than "server is down". Here's one that throws exceptions to indicate an invalid login attempt. This is the kind of thing I was thinking about with the String constructors.
Now, for "server is down", we probably don't have an "if" at all; we probably try to connect to something, and fail. This is the case that Jim brings up, about wrapping system exceptions in custom ones:
Custom exceptions should not be created if an equally meaningful standard exception exists, and maybe even if it's slightly less meaningful. You must be careful about doing too much with custom and checked exceptions because as an API designer, you don't want people to have to dig too deep into your code to understand why a particular exception is thrown.
Some other things to consider:
Only throw checked exceptions when it's possible to recover, otherwise just throw runtime exceptions. The whole point of an exception is to recover from a situation, and if you cannot recover from it - what's the point of checking it?
I've seen a lot of code where people have written a detailed exception library and are very proud of it and like to throw and catch way too much. Checked exceptions are one of the tools that should be used only with very good reasons.
Joined: May 28, 2007
Greetings to all! I just didn't wanna pass the opportunity to thank all of you guys for helping me solve my doubts. I suppose you can consider this thread closed. God Bless,