• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Try/Catch question

 
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok say i have the following:



First the reason I am wanting to throw the exception in both the executeSprocInsert and createItem function is because
just system.out.println the message in the createItem method wouldn't work in web apps, so i was just gonna throw an
exception so i could handle it any way i wanted in any app.

Is this a good or bad design, if bad, how could I improve the structure?

Thanks,

Justin
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the point of catching an exception only to rethrow the same exception? Why not just let the original exception propagate outward?
 
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I generally don't like catching one exception and throwing another one. It can make debugging harder, because if you get a stack trace, you can only track the problem back to where you threw the new exception. Sometimes you have no choice, because you want to throw a different exception, or add information or something like that. I don't see you doing that here, so what's the purpose of catching and rethrowing? In any case, you can wrap one exception in another, which can make debugging later so much easier!
 
Justin Fox
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh ok, so should i just take out the throws sqlexception and the try/catch in the executeSprocInsert, remove the try/catch in createItem() and just try/catch in the main?

Thanks,

Justin
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you have nothing to do, it's useless -- in fact, disruptive -- to catch the exception only to rethrow it.

Since you mentioned web apps, I'll focus on those.

Pretty much the only times you should catch an exception are:

1) When you want to stop it and take some other action. For example, catching a NumberFormatException when parsing an integer to provide a default or report the error to the user in a form other than an exception. (Exceptions should never be used to report data entry errors).

2) When you want to convert one exception to another type. For example to "convert" an exception of one type to a ServletException because that's all that's allowed to propagate outward. In this case, the information in the original exception should not be lost, so attach it to the new exception as its cause.

Otherwise, you should just let the exceptions propagate outward uninterrupted so that whatever mechanism you have declared in the deployment descriptor can handle all such exceptions in a common and deterministic manner.
 
Justin Fox
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cool, alright..

But what if someone is inserting/Updating inventory into the database from front end app, And the modelnumber is the primary key,
and they enter the same model number, shouldn't I catch the sqlexception and let them know that they can't insert duplicates?

Or should I query the db before I call the insert to see if the modelnumber they entered is already there? And would either approach
be substantially more effecient than the other?

I'm not trying to challenge the idea that catching one exception and throwing that same one is dumb, but I just need to know how
to redo the code so it will be very re-usable and some-what efficient.

Consider this code for my question.



Thanks for all the info,

Justin
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Justin Fox wrote:Cool, alright..

But what if someone is inserting/Updating inventory into the database from front end app, And the modelnumber is the primary key, and they enter the same model number, shouldn't I catch the sqlexception and let them know that they can't insert duplicates?
. . .
Justin


I think the exception should be handled by the code that can correct the situation in an intelligent manner. I suspect that the suggestion for number 1 from Bear might mean that you shouldn't use an exception to report data entry errors might be referring to reporting it in lower-levels that don't have the context to do something about it, but that's just a guess - I might be missing something.

I'm not a Java expert, but I've had lots of C++ experience, and that's what I'm going on here.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, Marty has it right -- that's exactly the scenario of #1. You catch the exception to do something else with it -- in this case, report the error to the user in a reasonable manner. Showing them a stack trace is not a "reasonable manner".

In no way is catching an exception simply to throw it again a useful exercise.
 
Marty Fried
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:Yes, Marty has it right -- that's exactly the scenario of #1. You catch the exception to do something else with it -- in this case, report the error to the user in a reasonable manner. Showing them a stack trace is not a "reasonable manner".

In no way is catching an exception simply to throw it again a useful exercise.


Oooh, my first post, and I didn't make a fool of myself!

But I should have proofed it better, since I noticed now that it's not worded well. Also, I should have made it clear that I thought he was doing the right thing. I have this bad habit of rushing to finish before someone gets in an answer that makes me look like I'm repeating their post.

Anyway, thanks for clearing it up.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch, Marty!
 
Justin Fox
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cool, got it now.

Thank,


Justin
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic