Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!
  • 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

urgent exception qn

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My exception hierarchy is as follows: custom exception class
MyException extending Exception. and MySQLException extending
MyException.
Exception->MyException->MySQLException
Now consider following case:
If there is a method m1 that has scope in which calls to two methods
m2 and m3 are made. m2 throws MyException and m2 throws
MySQLException.
Now how should the throws clause look like ?
Should it be
1) m1() throws MyException, MySQLException or
2) m1 throws MyException
My choice in (2).
In short: when there are parent and child exceptions thrown in
implementation should we go with approach (2) always throw parent ?
Now another point is if there is a method m4() that calls m1(). Just
looking at the signature of m1() it seems that MyException is thrown
here. But how will the caller client would know that m1() throws
MySQLException in some condition and for other condition throws
MyException. If we go with approach (1), from the signature itself the
caller would know that there can be 2 separate exceptions that may be
thrown from method m1(). This can be a justification for approach(1) but I personally think javadoc with approach(2) is the way to go.
What do you think ?
 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't think of a good reason for MySQLException to exist. You should either mask the fact that it is an SQLException or just let the SQLException go uncaught.
 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd go with approch 2 in general. Any method that call method1 can choose to handle the general exception MyException only or if it knows about the more specific one it can choose to handle MySQLException first and then the more general MyException. But Jon has a point. Are you trying to wrap a SQLException - why? Let it remain a SQLException and either catch it and handle it right away or declare it in the throws clause for another method to handle.
 
My pie came with a little toothpic holding up this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic