what is the best practice for using exceptions ?
hello
I would like to know when to do I have to use
1:
myMethod ()throws Exception
2:
myMethod ()throws MyException
3:
myMethod (){
try{}catch(SQLException sqlException){}
}
4 :
myMethod ()throws MyException{
try{}catch (ClassNotFoundException ex){thrownew MyException("error" ,ex)}
}
Exception ,ClassNotFoundException and SQLException are just an example
any other exception can be in their place
thank you in advance
> hello
>
> I would like to know when to do I have to use
>
> 1:
> myMethod () throws Exception
Hardly ever. If you can't work out whether this is appropriate or not, it isn't, basically
> 2:
> myMethod () throws MyException
Most of the time, if you like checked exceptions. When the exception can be recovered from
> 3:
> myMethod () {
> try {} catch(SQLException sqlException){}
> }
>
Never ever ever. Don't just swallow exceptions
> 4 :
> myMethod () throws MyException {
> try{} catch (ClassNotFoundException ex) {throw new
> MyException("error" ,ex)}
> }
>
Opinions vary on this. If MyException is an unchecked exception, I like this. If not, you're just replacing one with the other. What for? Others will have different opinions though, and not necessarily wrong
> Exception ,ClassNotFoundException and SQLException
> are just an example
> any other exception can be in their place
> thank you in advance
Any other exceptions? Can you really treat SQLException and ClassNotFoundException the same way? One means there was a database problem, which may well be recoverable. The other? What is your app really supposed to do if it can't find a class? Rarely, this will be recoverable, perhaps. But not usually
> hello
>
> I would like to know when to do I have to use
>
> 1:
> myMethod () throws Exception
Never appropriate.
> 2:
> myMethod () throws MyException
Appropriate if the code within myMethod potentially throws MyException and you don't want to handle it within myMethod.
> 3:
> myMethod () {
> try {} catch(SQLException sqlException){}
> }
>
Appropriate if the code within the try block potentially throws a SQLException and you want to handle it within myMethod (e.g. logging, notify user).
> 4 :
> myMethod () throws MyException {
> try{} catch (ClassNotFoundException ex) {throw new
> MyException("error" ,ex)}
> }
>
Appropriate if the code within the try block potentially throws a ClassNotFoundException and you want to wrap it in a MyException to be handled as such somewhere higher in the call chain.
>
> Exception ,ClassNotFoundException and SQLException
> are just an example
> any other exception can be in their place
> thank you in advance
You're welcome in advance.
dwga at 2007-7-29 16:52:31 >
[repost deleted]
Stupid connection problem
Message was edited by:
dwg
dwga at 2007-7-29 16:52:31 >
> > hello
> >
> > I would like to know when to do I have to use
> >
> > 1:
> > myMethod () throws Exception
>
> Never appropriate.
I actually add that signature to methods in plugin interfaces (that other developers implements). I don't see why other developers should be forced to convert from one exception to another just because they want to throw something back to the framework.
Kaj
kajbja at 2007-7-29 16:52:31 >
> I actually add that signature to methods in plugin
> interfaces (that other developers implements). I
> don't see why other developers should be forced to
> convert from one exception to another just because
> they want to throw something back to the framework.
I get your point, and it's a valid one.
However that leads to inevitable code like thistry {
myMethod();
} catch (Exception e) {
...
}
which I just cringe thinking about.
dwga at 2007-7-29 16:52:31 >
> > I actually add that signature to methods in plugin
> > interfaces (that other developers implements). I
> > don't see why other developers should be forced to
> > convert from one exception to another just because
> > they want to throw something back to the framework.
>
>
> I get your point, and it's a valid one.
> However that leads to inevitable code like
> thistry {
>myMethod();
> tch (Exception e) {
> ...
> }
which I just cringe thinking about.
I liked my answer to that one. It leaves a lot of wiggle room
ok thank you
this is was a great help ,but this courage me to ask you another question
suppose we have
public User myDataBaseMethodFindUser()
{
//...some declaration here
resultSet= sqlfindUser.executeQuery();//checked exception not treated here
User user=null;
if(resultSet.next())
{
user = new User(resultSet.getString(1));
}
return user;
}
ok this method return user
this method is going to be called in the main method
public static void main(String args[]) {
//some declarations .....
User user = obj.myDataBaseMethodFindUser();
System.out.println(" the user name = "user.getName());
}
the line resultSet= sqlfindUser.executeQuery(); may generate an exception
but also we may have user == null
how would you treat the exception ,and how would you treat the null user
my solution :
in the main method I check if the user is not null
and I consider that the user can't fix the sql exception
so I just logge the exception to a file
is this the best practice ?
> > I actually add that signature to methods in plugin
> > interfaces (that other developers implements). I
> > don't see why other developers should be forced to
> > convert from one exception to another just because
> > they want to throw something back to the framework.
>
>
> I get your point, and it's a valid one.
> However that leads to inevitable code like
> thistry {
>myMethod();
> tch (Exception e) {
> ...
> }
which I just cringe thinking about.
Code should always be written in a defensive manner, especially if you are writing frameworks. Expect the unexpected, that means that you sometimes have to wrap your call in catch Exception blocks. You usually don't want exceptions from plugins/extensions to be propagated into your core. (But don't swallow the exceptions, do at least log them)
Kaj
kajbja at 2007-7-29 16:52:31 >
thank you georgemcand dwg ,I gave you the stars
and thank to every one
now could any one tell me what does he think about my last question ?
> my solution :
> in the main method I check if the user is not null
> and I consider that the user can't fix the sql
> exception
> so I just logge the exception to a file
> is this the best practice ?
Sounds good.
kajbja at 2007-7-29 16:52:31 >
>> myMethod () throws MyException {
>> try{} catch (ClassNotFoundException ex) {throw new
>> MyException("error" ,ex)}
>> }
>
> Appropriate if the code within the try block potentially throws a
> ClassNotFoundException and you want to wrap it in a MyException to be
> handled as such somewhere higher in the call chain.
Indeed. Think about layers of abstraction. The throws clause of a method
is part of its signature. If you don't let the implementation details of a layer
leak out to higher layers, don't let implementation-specific exceptions
leak out either.
