How about throwing 5 different types of exception?
I have a method which can potentially throw 5 types of exceptions. But is it good to throw them as 5 types or is it better to reduce it to 2 or 3 at the max?
Cause I don't know whether an API user will like to have 5 catch blocks. Ofcourse, they always have the choice of doing a catch all exception, but when I write the javadoc, will it be weird to say that I will throw 5 type of exceptions if you want to call this method?
[440 byte] By [
sri1025a] at [2007-10-3 3:33:46]
It depends. You may want 5 types if you're going to use the catch blocks for flow control. But that's not good practice. Can't you just throw Exception and insert a unique message?
> I have a method which can potentially throw 5 types
> of exceptions. But is it good to throw them as 5
> types or is it better to reduce it to 2 or 3 at the
> max?
>
> Cause I don't know whether an API user will like to
> have 5 catch blocks. Ofcourse, they always have the
> choice of doing a catch all exception, but when I
> write the javadoc, will it be weird to say that I
> will throw 5 type of exceptions if you want to call
> this method?
Is someone going to catch those and do something different with each one? (And that means exactly that - that they are going to catch them and not that they might catch them.)
If yes then you need five. If not then there is no reason to have more than one.
> It depends. You may want 5 types if you're going to
> use the catch blocks for flow control.
Exception as GOTO? Not a good idea, IMO.
> But that's not good practice.
And in yours, thank goodness.
> Can't you just throw Exception and insert a unique message?
I'd prefer more illustrative Exceptions that tell me what's happening rather than a generic exception with messages.
For example, Rod Johnson takes java.sql.SQLException and maps it using SQL error codes and states to a wider variety of unchecked exceptions (e.g., org.springframework.dao package) that give more insight into what's going on that checking codes.
You can compromise by making them unchecked rather than checked. I think that's a trend these days. C# went that way, and if Spring is any guide they're using unchecked exceptions more.
%
> I have a method which can potentially throw 5 types
> of exceptions. But is it good to throw them as 5
> types or is it better to reduce it to 2 or 3 at the
> max?
Can we know what exceptions they are? Are they your customized ones?
If they are your customized exceptions, then you can do something like this:
MySuperExceptionOne extends Exception {
//...
}
MySuperExceptionYwo extends Exception {
//...
}
MyExceptionA extends MySuperExceptionOne {
//...
}
MyExceptionB extends MySuperExceptionOne {
//...
}
MyExceptionC extends MySuperExceptionTwo {
//...
}
MyExceptionD extends MySuperExceptionTwo {
//...
}
MyExceptionE extends MySuperExceptionTwo {
//...
}
And now, to use those exceptions, you can simply do this:
/*
* Instead of declaring your method
* throwing all those 5 exceptions,
* just do it (see below)
*/
void myMethod() throws MySuperExceptionOne, MySuperExceptionTwo {
//...
}
> Cause I don't know whether an API user will like to
> have 5 catch blocks.
The user of your method, that is, another programmer, is the person who decides if writing 5 catch blocks will be good or not. Besides, if you write your exceptions in the way I exposed above, then the other programmer can simply write two catch blocks, just catching MySuperExceptionOne and MySuperExceptionTwo. Not to mention that the other programmer can always write only one catch block, by catching the generic Exception.
And even if the exceptions are not your customized ones, that is, they belong to an API that you are using, try to investigate whether these exceptions are organized in a relationship of super/sub exceptions. Generally they are, if this API has a good design. A good example is the way those classes of Java platform are organized. Spend some time downloading and taking a look at the source code of Java. You can learn a lot. See how those various kinds of exceptions are handled. Notice how those exceptions are organized in a structure of super/sub classes. Notice that there are some criteria in this organization. You can do something similiar.
> Ofcourse, they always have the
> choice of doing a catch all exception, but when I
> write the javadoc, will it be weird to say that I
> will throw 5 type of exceptions if you want to call
> this method?
I do not think that it is weird. Sometimes it is useful. API documentation (javadoc) exists to be consulted. If you think that giving detailed informations about your method will be good, then do it. Even if you adopt a solution like the one I proposed above, you can detail your exceptions when you are writing the javadoc. See below:
/*
* You can do this, sometimes it is informatively useful.
*
* @throws MyExceptionA if blah blah blah
* @throws MyExceptionB if bleh bleh bleh
* @throws MyExceptionC if blih blih blih
* @throws MyExceptionD if bloh bloh bloh
* @throws MyExceptionE if bluh bluh bluh
*/
void myMethod() throws MySuperExceptionOne, MySuperExceptionTwo {
//...
}
>
> For example, Rod Johnson takes java.sql.SQLException
> and maps it using SQL error codes and states to a
> wider variety of unchecked exceptions (e.g.,
> org.springframework.dao package) that give more
> insight into what's going on that checking codes.
>
As in spring itself?
Libraries need to use a wide range of exceptions including specialized ones because a library is intended to be used in a wide number of applications.
That isn't the same for an application however.
> >
> > For example, Rod Johnson takes
> java.sql.SQLException
> > and maps it using SQL error codes and states to a
> > wider variety of unchecked exceptions (e.g.,
> > org.springframework.dao package) that give more
> > insight into what's going on that checking codes.
> >
>
> As in spring itself?
>
> Libraries need to use a wide range of exceptions
> including specialized ones because a library is
> intended to be used in a wide number of
> applications.
>
> That isn't the same for an application however.
This library happens to be dealing with SQL in the situation I cited, so I think it applies to any application that uses SQL, too.
I only cited it as an example for a situation where I'd prefer more specialized exceptions rather than just getting one generic one and having to figure out what's going on by catching a single exception, examining messages, and writing handler code like this:
catch (Exception e)
{
if (e.getMessage().equals("this happened"))
{
thisHandler();
}
else if (e.getMessage().equals("that happened"))
{
thatHandler();
}
else if (e.getMessage().equals("something else happened"))
{
somethingElseHandler();
}
else
{
defaultHandler();
}
}
Personally, I think a design like that doesn't deserve to be called object-oriented. I much prefer more exception types being thrown to just seeing "throws Exception". ANYTHING can happen then.
I think custom exceptions that mirror business situations are useful.
%
Thank you all for the suggestions.
In my situation I need to have 5 different types of exceptions (they don't relate to one another). And I want to inform the user of the API about the exact reason why the method failed, so throwing 5 exceptions may actually help I guess.
Thank you and I apologize for the late reply as I was on weekend holidays :)
> >
> > That isn't the same for an application however.
>
> This library happens to be dealing with SQL in the
> situation I cited, so I think it applies to any
> application that uses SQL, too.
>
> I only cited it as an example for a situation where
> I'd prefer more specialized exceptions rather than
> just getting one generic one and having to figure out
> what's going on by catching a single exception,
> examining messages, and writing handler code like
> this:
>
Yes that is why libraries have multiple exceptions.
On the other hand an application might need to handle a single type of error (like a connection failure) one way and all others another (like SQL syntax errors). If an app is using a library then that library should be providing a full range of exceptions.If the app isn't using a library then it should only have the single exception that it needs to handle
>
> Personally, I think a design like that doesn't
> deserve to be called object-oriented. I much prefer
> more exception types being thrown to just seeing
> "throws Exception". ANYTHING can happen then.
>
Which in my original post I asked if the OP was using those exceptions.
> I think custom exceptions that mirror business
> situations are useful.
I never said otherwise.
I wasn't addressing that there were too few exceptions but rather that there were too many. There is no reason for an app to define 100 different exceptions when only there are only two different paths that exceptions can take.
> Yes that is why libraries have multiple exceptions.
>
> On the other hand an application might need to handle
> a single type of error (like a connection failure)
> one way and all others another (like SQL syntax
> errors). If an app is using a library then that
> library should be providing a full range of
> exceptions.If the app isn't using a library then
> it should only have the single exception that it
> needs to handle
You're describing what Spring has. DataAccessException is the superclass, and there are nine subclasses that provide more detail.
> Which in my original post I asked if the OP was using
> those exceptions.
>
> I think custom exceptions that mirror business
> situations are useful.
>
> I never said otherwise.
I don't think I implied that you did.
> I wasn't addressing that there were too few
> exceptions but rather that there were too many.
> There is no reason for an app to define 100
> different exceptions when only there are only two
> different paths that exceptions can take.
But what about 5? 100 is obviously too many. What's the cutoff? What feels like too many?
If I need two lines to list the exceptions in my editor, or if I have to scroll too far, there's too much going on.
I wonder if an excessive exception list is a subtle indicator that your method might need refactoring? If it gets too long, or has too many parameters, or throws too many exceptions, perhaps it's trying to do too much. A better abstraction would split it into two more more methods.
%
>
> You're describing what Spring has.
> DataAccessException is the superclass, and there are
> nine subclasses that provide more detail.
>
Spring is a library. Libraries need multiple exceptions.
Most developers do not work on libraries. They work on applications.
Applications are not the same as libraries. One should not apply the best practices of libraries to applications because the needs are different.
The vast majority of the time the business needs of an application (not a library) is very limited in the number of exceptions that a developer should create.
>
> > I wasn't addressing that there were too few
> > exceptions but rather that there were too many.
> > There is no reason for an app to define 100
> > different exceptions when only there are only two
> > different paths that exceptions can take.
>
> But what about 5? 100 is obviously too many. What's
> the cutoff? What feels like too many?
>
Simple.
Does the application use each individual exception in catch in such a way that is different than all the other exceptions that are defined. Then it should exist. If not then it should be merged until that is true.
> If I need two lines to list the exceptions in my
> editor, or if I have to scroll too far, there's too
> much going on.
>
Not sure what you mean but typically I get by with either one exception that I created or with none.
> I wonder if an excessive exception list is a subtle
> indicator that your method might need refactoring?
> If it gets too long, or has too many parameters, or
> throws too many exceptions, perhaps it's trying to
> do too much. A better abstraction would split it
> into two more more methods.
>
I hadn't considered that. Certainly if the code is duplicated it is a problem. But that probably suggests that the exception shouldn't exist in the first place (application exception.)
> >
> > You're describing what Spring has.
> > DataAccessException is the superclass, and there
> are
> > nine subclasses that provide more detail.
> >
>
> Spring is a library. Libraries need multiple
> exceptions.
>
> Most developers do not work on libraries. They work
> on applications.
>
> Applications are not the same as libraries. One
> should not apply the best practices of libraries to
> applications because the needs are different.
>
> The vast majority of the time the business needs of
> an application (not a library) is very limited in the
> number of exceptions that a developer should create.
I think I see what you're saying now.
> Simple.
>
> Does the application use each individual exception in
> catch in such a way that is different than all the
> other exceptions that are defined. Then it should
> exist. If not then it should be merged until that is
> true.
Good argument.
> Not sure what you mean but typically I get by with
> either one exception that I created or with none.
True - I've got to admit that I don't have a wealth of application-specific exceptions lying around.
> I wonder if an excessive exception list is a subtle
> indicator that your method might need refactoring?
> If it gets too long, or has too many parameters, or
> throws too many exceptions, perhaps it's trying to
> do too much. A better abstraction would split it
>into two more more methods.
>
>
> I hadn't considered that. Certainly if the code is
> duplicated it is a problem. But that probably
> suggests that the exception shouldn't exist in the
> first place (application exception.)
%
Hi,
In our application We need to catch the Runtime Exceptions. that are generated in the application.
i have an idea of making a base exception class which extends the exception
and in that class making a Handler method and catching all the exceptions within this handler and displaying the message to UI and Reporting to Log.
I need to have an other option which is more suitable than this.
> Hi,> > In our application We need to catch the Runtime> Exceptions. that are generated in the application.Woah slow down here buddy.Why?
> > Hi,
> >
> > In our application We need to catch the Runtime
> > Exceptions. that are generated in the
> application.
>
> Woah slow down here buddy.
>
> Why?
That's a very common situation.
You're dealing with a fairly huge system with lots of independent subsystems. A NPE is thrown in one of these subsystems, but to avoid the whole system to crash, you delegate catching of such Throwables as close as you can to the client, and just send him back an error message (and warn the admin so that proper action can be taken to repair the defect subsystem, possibly redeploying it while keeping the system up and running).
@Ajay_reddy : open a new thread, don't hijack this one
Edit : Yeah, "Throwable" may be a bit extreme, since Errors will most likely leave the JVM in an unpredictable state, let's say "Exceptions".
Message was edited by:
Torajirou
I suggest reading section 8 of the excellent Effective Java Programming Language Guide by Joshua Bloch:
Item 39: Use exceptions only for exceptional conditions
Item 40: Use checked exceptions for recoverable conditions and run-time exceptions for programming errors
Item 41: Avoid unnecessary use of checked exceptions
Item 42: Favor the use of standard exceptions
Item 43: Throw exceptions appropriate to the abstraction
Item 44: Document all exceptions thrown by each method
Item 45: Include failure-capture information in detail messages
Item 46: Strive for failure atomicity
Item 47: Don't ignore exceptions
YoGeea at 2007-7-21 10:12:59 >
