You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Navjot Singh <na...@net4india.net> on 2003/04/05 14:17:09 UTC
Best way for Database Exception Handling
hi gurus,
I have some facade layer for my database.
That every method in that facade layer, naturally, *catches* SQLException
and in return
throw new DBException( sqlexception);
My DBException is extending java.lang.Exception. So, I have to explicity
throw it and later catch it in my business logic layer as well. Obviously,
if there is DBException, even business logic CANNOT do anything but to pass
the exception to presentation layer where it can be caught nicely by
<global-exception>
What if i change my DBException to extend RunTimeException.
__That way__
+ I need not to explicity throw and catch DBException.
+ Few of my methods won't have to send 2-3 exceptions like
getBookList(int id) throws DBException, NoBookException
__Qs__
+ Would this exception still be catched by <global-exception>?
+ If YES, is it a nice thing to do?
Any comments are welcome
- Navjot Singh
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Harish Krishnaswamy <wh...@yahoo.com>.
IMO, like the name suggests, if your app. has no way to handle the exception then I think it
should be a RuntimeException.
-Harish
--- Navjot Singh <na...@net4india.net> wrote:
> hi harish,
>
> My DBException actually contains other things like <err_id> etc. So if i
> throw nested exception, it's good for me.
> Anyway, we seem to have lost from the main focus.
> **
> Would it be good to extend RuntimeException, rather than Exception, from my
> DBException?
> so that i need not to catch/throw them in my method on the way back to
> controller.
> **
>
> regards
> Navjot Singh
>
> ----- Original Message -----
> From: "Harish Krishnaswamy" <wh...@yahoo.com>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> Sent: Monday, April 07, 2003 2:15 AM
> Subject: Re: Best way for Database Exception Handling
>
>
> | When I say "handle it in the controller" I don't mean to handle
> SQLException specifically but
> | rather Exception in general. Because in an event where the model cannot
> handle an exception there
> | is nothing the controller can do but show a user friendly message. And you
> don't need to handle
> | SQLException and every other EIS exception specifically to do show/log a
> message.
> |
> | -Harish
> |
> |
> | --- Guido <gu...@ribera.tel.uva.es> wrote:
> | > I don't like your idea, Harish.
> | >
> | > What if your information systems (EIS) change? I mean, i.e. you are
> using
> | > a Oracle database, your requirements change and you must store your data
> | > in a XML file. SQLException has no sense in your controller layer.
> | >
> | > I personally prefer to catch my EIS exceptions (SQLException or
> | > whatever) in the business logic layer and throw a EISException or
> | > something like that.
> | >
> | > Regards,
> | > Guido.
> | >
> | > On Sat, 5 Apr 2003, Harish Krishnaswamy wrote:
> | >
> | > } If your business logic cannot do anything with your DBException, what
> is the need for defining
> | > one
> | > } such exception? Why not just throw the SQLException and handle it in
> the controller?
> | > }
> | > } -Harish
> | > }
> | > }
> | > } --- Navjot Singh <na...@net4india.net> wrote:
> | > } > hi gurus,
> | > } >
> | > } > I have some facade layer for my database.
> | > } > That every method in that facade layer, naturally, *catches*
> SQLException
> | > } > and in return
> | > } > throw new DBException( sqlexception);
> | > } >
> | > } > My DBException is extending java.lang.Exception. So, I have to
> explicity
> | > } > throw it and later catch it in my business logic layer as well.
> Obviously,
> | > } > if there is DBException, even business logic CANNOT do anything but
> to pass
> | > } > the exception to presentation layer where it can be caught nicely by
> | > } > <global-exception>
> | > } >
> | > } > What if i change my DBException to extend RunTimeException.
> | > } >
> | > } > __That way__
> | > } > + I need not to explicity throw and catch DBException.
> | > } > + Few of my methods won't have to send 2-3 exceptions like
> | > } > getBookList(int id) throws DBException, NoBookException
> | > } >
> | > } > __Qs__
> | > } > + Would this exception still be catched by <global-exception>?
> | > } > + If YES, is it a nice thing to do?
> | > } >
> | > } > Any comments are welcome
> | > } > - Navjot Singh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Navjot Singh <na...@net4india.net>.
hi harish,
My DBException actually contains other things like <err_id> etc. So if i
throw nested exception, it's good for me.
Anyway, we seem to have lost from the main focus.
**
Would it be good to extend RuntimeException, rather than Exception, from my
DBException?
so that i need not to catch/throw them in my method on the way back to
controller.
**
regards
Navjot Singh
----- Original Message -----
From: "Harish Krishnaswamy" <wh...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Monday, April 07, 2003 2:15 AM
Subject: Re: Best way for Database Exception Handling
| When I say "handle it in the controller" I don't mean to handle
SQLException specifically but
| rather Exception in general. Because in an event where the model cannot
handle an exception there
| is nothing the controller can do but show a user friendly message. And you
don't need to handle
| SQLException and every other EIS exception specifically to do show/log a
message.
|
| -Harish
|
|
| --- Guido <gu...@ribera.tel.uva.es> wrote:
| > I don't like your idea, Harish.
| >
| > What if your information systems (EIS) change? I mean, i.e. you are
using
| > a Oracle database, your requirements change and you must store your data
| > in a XML file. SQLException has no sense in your controller layer.
| >
| > I personally prefer to catch my EIS exceptions (SQLException or
| > whatever) in the business logic layer and throw a EISException or
| > something like that.
| >
| > Regards,
| > Guido.
| >
| > On Sat, 5 Apr 2003, Harish Krishnaswamy wrote:
| >
| > } If your business logic cannot do anything with your DBException, what
is the need for defining
| > one
| > } such exception? Why not just throw the SQLException and handle it in
the controller?
| > }
| > } -Harish
| > }
| > }
| > } --- Navjot Singh <na...@net4india.net> wrote:
| > } > hi gurus,
| > } >
| > } > I have some facade layer for my database.
| > } > That every method in that facade layer, naturally, *catches*
SQLException
| > } > and in return
| > } > throw new DBException( sqlexception);
| > } >
| > } > My DBException is extending java.lang.Exception. So, I have to
explicity
| > } > throw it and later catch it in my business logic layer as well.
Obviously,
| > } > if there is DBException, even business logic CANNOT do anything but
to pass
| > } > the exception to presentation layer where it can be caught nicely by
| > } > <global-exception>
| > } >
| > } > What if i change my DBException to extend RunTimeException.
| > } >
| > } > __That way__
| > } > + I need not to explicity throw and catch DBException.
| > } > + Few of my methods won't have to send 2-3 exceptions like
| > } > getBookList(int id) throws DBException, NoBookException
| > } >
| > } > __Qs__
| > } > + Would this exception still be catched by <global-exception>?
| > } > + If YES, is it a nice thing to do?
| > } >
| > } > Any comments are welcome
| > } > - Navjot Singh
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Navjot Singh <na...@net4india.net>.
thanks Ian.
The way i have done is this:
I catch SQLException in my db facade and wrap this in DBException. i.e
try{
prepStsmt.executeUpdate();
}catch(SQLException e) {
//log here
throw new DBException(sqle);
}
Thus, almost every method in dblayer is throwing DBException that had to be
caught in business logic :-(
Here is the beneift of EJBs that i am not using in the project
In the business logic layer, i catch DBException ( i had to catch it as i
need to return the connection back to pool)
and throw other exception AppException( similar to your ModelException). The
only diff is that my AppException is extending RuntimeException. So i need
NOT to explicity throw it from business logic.
Controller class is catching *every* Exception so that won't cry. Later, i
have set web.xml to handle AppException nicely.
Hope i am doing right. Btw, i liked your idea to distinguish among the kind
of exception.
regards
Navjot Singh
----- Original Message -----
From: "Ian Hunter" <ih...@hunterweb.net>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Monday, April 07, 2003 6:23 PM
Subject: Re: Best way for Database Exception Handling
| The way I do it is this: within my business model layer, I have an
| exception "ModelException" that extends plain old "Exception." I create
| RecAddException, RecUpdateException, RecDeleteException, etc. etc. from
that
| base ModelException -- then, whatever real exception I get, I wrap with
one
| of those and let the controller act appropriately. For instance, if I'm
| adding a record to some kind of persistent storage, regardless of the
error
| I get (RemoteException, SQLException, whatever) I'd catch that and throw a
| RecAddException. That way, if the underlying persistence layer changes,
the
| controller shouldn't care about it, nor should an application, if
somewhere
| down the road the interface is Swing instead of HTML.
|
| ???
|
| ----- Original Message -----
| From: "Harish Krishnaswamy" <wh...@yahoo.com>
| To: "Struts Users Mailing List" <st...@jakarta.apache.org>
| Sent: Sunday, April 06, 2003 4:45 PM
| Subject: Re: Best way for Database Exception Handling
|
|
| > When I say "handle it in the controller" I don't mean to handle
| SQLException specifically but
| > rather Exception in general. Because in an event where the model cannot
| handle an exception there
| > is nothing the controller can do but show a user friendly message. And
you
| don't need to handle
| > SQLException and every other EIS exception specifically to do show/log a
| message.
| >
| > -Harish
| >
| >
| > --- Guido <gu...@ribera.tel.uva.es> wrote:
| > > I don't like your idea, Harish.
| > >
| > > What if your information systems (EIS) change? I mean, i.e. you are
| using
| > > a Oracle database, your requirements change and you must store your
data
| > > in a XML file. SQLException has no sense in your controller layer.
| > >
| > > I personally prefer to catch my EIS exceptions (SQLException or
| > > whatever) in the business logic layer and throw a EISException or
| > > something like that.
| > >
| > > Regards,
| > > Guido.
| > >
| > > On Sat, 5 Apr 2003, Harish Krishnaswamy wrote:
| > >
| > > } If your business logic cannot do anything with your DBException,
what
| is the need for defining
| > > one
| > > } such exception? Why not just throw the SQLException and handle it in
| the controller?
| > > }
| > > } -Harish
| > > }
| > > }
| > > } --- Navjot Singh <na...@net4india.net> wrote:
| > > } > hi gurus,
| > > } >
| > > } > I have some facade layer for my database.
| > > } > That every method in that facade layer, naturally, *catches*
| SQLException
| > > } > and in return
| > > } > throw new DBException( sqlexception);
| > > } >
| > > } > My DBException is extending java.lang.Exception. So, I have to
| explicity
| > > } > throw it and later catch it in my business logic layer as well.
| Obviously,
| > > } > if there is DBException, even business logic CANNOT do anything
but
| to pass
| > > } > the exception to presentation layer where it can be caught nicely
by
| > > } > <global-exception>
| > > } >
| > > } > What if i change my DBException to extend RunTimeException.
| > > } >
| > > } > __That way__
| > > } > + I need not to explicity throw and catch DBException.
| > > } > + Few of my methods won't have to send 2-3 exceptions like
| > > } > getBookList(int id) throws DBException, NoBookException
| > > } >
| > > } > __Qs__
| > > } > + Would this exception still be catched by <global-exception>?
| > > } > + If YES, is it a nice thing to do?
| > > } >
| > > } > Any comments are welcome
| > > } > - Navjot Singh
| > > } >
| > > } >
| > > }
| > ---------------------------------------------------------------------
| > > } > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
| > > } > For additional commands, e-mail:
struts-user-help@jakarta.apache.org
| > > } >
| > > }
| > > }
| > > } __________________________________________________
| > > } Do you Yahoo!?
| > > } Yahoo! Tax Center - File online, calculators, forms, and more
| > > } http://tax.yahoo.com
| > > }
| >
> } ---------------------------------------------------------------------
| > > } To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
| > > } For additional commands, e-mail: struts-user-help@jakarta.apache.org
| > > }
| > >
| > >
| >
> ------------------------------------------------------------------------
| > > Guido Garcia Bernardo
| > > guigar@ribera.tel.uva.es
| > > palmerabollo@hotmail.com
| > > "stat rosa pristina
| > > nomine, nomina nuda tenemus."
| >
> ------------------------------------------------------------------------
| > >
|
http://members.ud.com/services/teams/team.htm?id=D8624419-BFB6-4772-A01A-004
| 5631F979F
| > >
| > > ---------------------------------------------------------------------
| > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
| > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
| > >
| >
| >
| > __________________________________________________
| > Do you Yahoo!?
| > Yahoo! Tax Center - File online, calculators, forms, and more
| > http://tax.yahoo.com
| >
| > ---------------------------------------------------------------------
| > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
| > For additional commands, e-mail: struts-user-help@jakarta.apache.org
| >
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: struts-user-help@jakarta.apache.org
|
|
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Ian Hunter <ih...@hunterweb.net>.
The way I do it is this: within my business model layer, I have an
exception "ModelException" that extends plain old "Exception." I create
RecAddException, RecUpdateException, RecDeleteException, etc. etc. from that
base ModelException -- then, whatever real exception I get, I wrap with one
of those and let the controller act appropriately. For instance, if I'm
adding a record to some kind of persistent storage, regardless of the error
I get (RemoteException, SQLException, whatever) I'd catch that and throw a
RecAddException. That way, if the underlying persistence layer changes, the
controller shouldn't care about it, nor should an application, if somewhere
down the road the interface is Swing instead of HTML.
???
----- Original Message -----
From: "Harish Krishnaswamy" <wh...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Sunday, April 06, 2003 4:45 PM
Subject: Re: Best way for Database Exception Handling
> When I say "handle it in the controller" I don't mean to handle
SQLException specifically but
> rather Exception in general. Because in an event where the model cannot
handle an exception there
> is nothing the controller can do but show a user friendly message. And you
don't need to handle
> SQLException and every other EIS exception specifically to do show/log a
message.
>
> -Harish
>
>
> --- Guido <gu...@ribera.tel.uva.es> wrote:
> > I don't like your idea, Harish.
> >
> > What if your information systems (EIS) change? I mean, i.e. you are
using
> > a Oracle database, your requirements change and you must store your data
> > in a XML file. SQLException has no sense in your controller layer.
> >
> > I personally prefer to catch my EIS exceptions (SQLException or
> > whatever) in the business logic layer and throw a EISException or
> > something like that.
> >
> > Regards,
> > Guido.
> >
> > On Sat, 5 Apr 2003, Harish Krishnaswamy wrote:
> >
> > } If your business logic cannot do anything with your DBException, what
is the need for defining
> > one
> > } such exception? Why not just throw the SQLException and handle it in
the controller?
> > }
> > } -Harish
> > }
> > }
> > } --- Navjot Singh <na...@net4india.net> wrote:
> > } > hi gurus,
> > } >
> > } > I have some facade layer for my database.
> > } > That every method in that facade layer, naturally, *catches*
SQLException
> > } > and in return
> > } > throw new DBException( sqlexception);
> > } >
> > } > My DBException is extending java.lang.Exception. So, I have to
explicity
> > } > throw it and later catch it in my business logic layer as well.
Obviously,
> > } > if there is DBException, even business logic CANNOT do anything but
to pass
> > } > the exception to presentation layer where it can be caught nicely by
> > } > <global-exception>
> > } >
> > } > What if i change my DBException to extend RunTimeException.
> > } >
> > } > __That way__
> > } > + I need not to explicity throw and catch DBException.
> > } > + Few of my methods won't have to send 2-3 exceptions like
> > } > getBookList(int id) throws DBException, NoBookException
> > } >
> > } > __Qs__
> > } > + Would this exception still be catched by <global-exception>?
> > } > + If YES, is it a nice thing to do?
> > } >
> > } > Any comments are welcome
> > } > - Navjot Singh
> > } >
> > } >
> > }
> ---------------------------------------------------------------------
> > } > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > } > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > } >
> > }
> > }
> > } __________________________________________________
> > } Do you Yahoo!?
> > } Yahoo! Tax Center - File online, calculators, forms, and more
> > } http://tax.yahoo.com
> > }
> > } ---------------------------------------------------------------------
> > } To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > } For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > }
> >
> >
> > ------------------------------------------------------------------------
> > Guido Garcia Bernardo
> > guigar@ribera.tel.uva.es
> > palmerabollo@hotmail.com
> > "stat rosa pristina
> > nomine, nomina nuda tenemus."
> > ------------------------------------------------------------------------
> >
http://members.ud.com/services/teams/team.htm?id=D8624419-BFB6-4772-A01A-004
5631F979F
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Harish Krishnaswamy <wh...@yahoo.com>.
When I say "handle it in the controller" I don't mean to handle SQLException specifically but
rather Exception in general. Because in an event where the model cannot handle an exception there
is nothing the controller can do but show a user friendly message. And you don't need to handle
SQLException and every other EIS exception specifically to do show/log a message.
-Harish
--- Guido <gu...@ribera.tel.uva.es> wrote:
> I don't like your idea, Harish.
>
> What if your information systems (EIS) change? I mean, i.e. you are using
> a Oracle database, your requirements change and you must store your data
> in a XML file. SQLException has no sense in your controller layer.
>
> I personally prefer to catch my EIS exceptions (SQLException or
> whatever) in the business logic layer and throw a EISException or
> something like that.
>
> Regards,
> Guido.
>
> On Sat, 5 Apr 2003, Harish Krishnaswamy wrote:
>
> } If your business logic cannot do anything with your DBException, what is the need for defining
> one
> } such exception? Why not just throw the SQLException and handle it in the controller?
> }
> } -Harish
> }
> }
> } --- Navjot Singh <na...@net4india.net> wrote:
> } > hi gurus,
> } >
> } > I have some facade layer for my database.
> } > That every method in that facade layer, naturally, *catches* SQLException
> } > and in return
> } > throw new DBException( sqlexception);
> } >
> } > My DBException is extending java.lang.Exception. So, I have to explicity
> } > throw it and later catch it in my business logic layer as well. Obviously,
> } > if there is DBException, even business logic CANNOT do anything but to pass
> } > the exception to presentation layer where it can be caught nicely by
> } > <global-exception>
> } >
> } > What if i change my DBException to extend RunTimeException.
> } >
> } > __That way__
> } > + I need not to explicity throw and catch DBException.
> } > + Few of my methods won't have to send 2-3 exceptions like
> } > getBookList(int id) throws DBException, NoBookException
> } >
> } > __Qs__
> } > + Would this exception still be catched by <global-exception>?
> } > + If YES, is it a nice thing to do?
> } >
> } > Any comments are welcome
> } > - Navjot Singh
> } >
> } >
> } > ---------------------------------------------------------------------
> } > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> } > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> } >
> }
> }
> } __________________________________________________
> } Do you Yahoo!?
> } Yahoo! Tax Center - File online, calculators, forms, and more
> } http://tax.yahoo.com
> }
> } ---------------------------------------------------------------------
> } To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> } For additional commands, e-mail: struts-user-help@jakarta.apache.org
> }
>
>
> ------------------------------------------------------------------------
> Guido Garcia Bernardo
> guigar@ribera.tel.uva.es
> palmerabollo@hotmail.com
> "stat rosa pristina
> nomine, nomina nuda tenemus."
> ------------------------------------------------------------------------
> http://members.ud.com/services/teams/team.htm?id=D8624419-BFB6-4772-A01A-0045631F979F
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Guido <gu...@ribera.tel.uva.es>.
I don't like your idea, Harish.
What if your information systems (EIS) change? I mean, i.e. you are using
a Oracle database, your requirements change and you must store your data
in a XML file. SQLException has no sense in your controller layer.
I personally prefer to catch my EIS exceptions (SQLException or
whatever) in the business logic layer and throw a EISException or
something like that.
Regards,
Guido.
On Sat, 5 Apr 2003, Harish Krishnaswamy wrote:
} If your business logic cannot do anything with your DBException, what is the need for defining one
} such exception? Why not just throw the SQLException and handle it in the controller?
}
} -Harish
}
}
} --- Navjot Singh <na...@net4india.net> wrote:
} > hi gurus,
} >
} > I have some facade layer for my database.
} > That every method in that facade layer, naturally, *catches* SQLException
} > and in return
} > throw new DBException( sqlexception);
} >
} > My DBException is extending java.lang.Exception. So, I have to explicity
} > throw it and later catch it in my business logic layer as well. Obviously,
} > if there is DBException, even business logic CANNOT do anything but to pass
} > the exception to presentation layer where it can be caught nicely by
} > <global-exception>
} >
} > What if i change my DBException to extend RunTimeException.
} >
} > __That way__
} > + I need not to explicity throw and catch DBException.
} > + Few of my methods won't have to send 2-3 exceptions like
} > getBookList(int id) throws DBException, NoBookException
} >
} > __Qs__
} > + Would this exception still be catched by <global-exception>?
} > + If YES, is it a nice thing to do?
} >
} > Any comments are welcome
} > - Navjot Singh
} >
} >
} > ---------------------------------------------------------------------
} > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
} > For additional commands, e-mail: struts-user-help@jakarta.apache.org
} >
}
}
} __________________________________________________
} Do you Yahoo!?
} Yahoo! Tax Center - File online, calculators, forms, and more
} http://tax.yahoo.com
}
} ---------------------------------------------------------------------
} To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
} For additional commands, e-mail: struts-user-help@jakarta.apache.org
}
------------------------------------------------------------------------
Guido Garcia Bernardo
guigar@ribera.tel.uva.es
palmerabollo@hotmail.com
"stat rosa pristina
nomine, nomina nuda tenemus."
------------------------------------------------------------------------
http://members.ud.com/services/teams/team.htm?id=D8624419-BFB6-4772-A01A-0045631F979F
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Best way for Database Exception Handling
Posted by Harish Krishnaswamy <wh...@yahoo.com>.
If your business logic cannot do anything with your DBException, what is the need for defining one
such exception? Why not just throw the SQLException and handle it in the controller?
-Harish
--- Navjot Singh <na...@net4india.net> wrote:
> hi gurus,
>
> I have some facade layer for my database.
> That every method in that facade layer, naturally, *catches* SQLException
> and in return
> throw new DBException( sqlexception);
>
> My DBException is extending java.lang.Exception. So, I have to explicity
> throw it and later catch it in my business logic layer as well. Obviously,
> if there is DBException, even business logic CANNOT do anything but to pass
> the exception to presentation layer where it can be caught nicely by
> <global-exception>
>
> What if i change my DBException to extend RunTimeException.
>
> __That way__
> + I need not to explicity throw and catch DBException.
> + Few of my methods won't have to send 2-3 exceptions like
> getBookList(int id) throws DBException, NoBookException
>
> __Qs__
> + Would this exception still be catched by <global-exception>?
> + If YES, is it a nice thing to do?
>
> Any comments are welcome
> - Navjot Singh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org