Depends on your situation.
If the SQL Exceptions are expected (i.e., a trigger could fail) then
yes, you will want to catch that and send the message back to the user.
However, if you are thinking JDBC is the way to go, you really should
use something like iBATIS that hides this kind of stuff from you.
Compared to the pile of code below, I would MUCH prefer writing this:
List results;
try{
results = sqlmap.executeQueryForList("myQuery", myParameters);
}catch(SqlMapException e){
// deal with one exception type
}
No need to build your sql statement (just say NO to
StringBuffer.append()), map parameters by numbers (YUCK), clean up
resources, etc...and you end up with very tight readable application
code.
Larry
>>> [EMAIL PROTECTED] 04/07/04 7:00 AM >>>
So, are there implied catches in there for SQLException (I assume there
are)?
In the innermost try block, does the catch rethrow the SQLException so
that it cascades to the outer blocks?
Just trying to understand the model.
Dean Hoover
Larry Meadors wrote:
>Yes.
>
>You really might want to consider a tool like iBATIS, but if you want
to
>do it yourself, here is the pattern:
>
>Connection c = null;
>try{
> //get connection
> try{
> // get statement
> try{
> // get result set
> // process result set
> }finally{
> // close result set if not null
> }
> }finally{
> // close statement if not null
> }
>}finally{
> //close connection if not null
>}
>
>Larry
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
