• 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

Wrapper Exception is good or not ??

 
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alway, i have been used Wrapper exception to hold real exception.

Such as ::

- SQLException have wrapper exception -> DatabaseException
- Exception in Business layer have wrapper exception -> BusinessException

Wrapper Exception is good or not ?? please share more detail.

thank you.

ps.
i think, it help me to debug/maintain code.
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general a class should only throw "meaningful" exceptions, so a CustomerDAO class could throw a SQLException, while a Customer class should not. In this example the Customer class could catch the SQLException and throw a more meaningful business exception (maybe as a wrapper of the original exception).

Just my 2 cents,

Jan
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've almost always had an application wrapper for Exception with some extra stuff around stack traces and messages, the ability chain a stack of them together and such. I've rarely found the need to have a whole hierarchy of application types, like IO, SQL, InvalidArgument and so on, because I rarely need to do different things in response to different exceptions. If you catch IO, do something, catch SQL do something else, catch InvalidArgument do something else you'd probably want the three types. And logging "Caught IO Exception" vs "Caught SQL Exception" doesn't count as something different.

I look forward to other opinions on this. Application requirements vary enough to give people very diffrent outlooks on exceptions.
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I do pretty much what Stan does, except I do have a few specific subclasses where I expect the caller to take action on the exception rather than let it bubble up to the controller to be logged.

For example, my DAO base class throws UniqueKeyViolatedException and ObjectNotFoundException but allows all other Hibernate exceptions (converted to unchecked exceptions by Spring) to propagate. These are both unchecked exceptions, by the way, since I also expect that sometimes the caller will consider the exception a logic error and not catch it.

At the root, there's a generic ServiceException as the base unchecked exception for wrapping other exceptions. It has the chaining features discussed above but not much else. AppException is the root checked exception, but I've been moving away from those due to their PITA factor.

One thing I do that I've seen most other people avoid (though I don't know why) is make use of Java's built-in exceptions when they make sense, mostly IllegalArgument/StateException. I've never gotten a reason other than "that's just how we do it" from those that avoid them. Anyone else have a reason?
 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I use IllegalArgumentException and IllegalStateException extensively.
 
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Harkness:


One thing I do that I've seen most other people avoid (though I don't know why) is make use of Java's built-in exceptions when they make sense, mostly IllegalArgument/StateException. I've never gotten a reason other than "that's just how we do it" from those that avoid them. Anyone else have a reason?



I tend to use these two quite a bit. But one reason I can think of avoiding these is that, many Java, J2EE api classes also throw these exceptions, and in most of those cases these exceptions would be unrecoverable at runtime, perhaps useful only during development.

So, if you want your calling code to catch some of the exceptions you throw, it will be hard to differentiate which (say) IllegalStateException is being thrown by your own code and is recoverable, and which is thrown by Java/J2EE libraries and should be allowed to bubble up.
 
reply
    Bookmark Topic Watch Topic
  • New Topic