• Post Reply Bookmark Topic Watch Topic
  • New Topic

Wrapper Exception is good or not ??  RSS feed

 
somkiat puisungnoen
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
  • 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.
 
Jan Rotthaus
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • 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
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • 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.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • 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?
 
Pho Tek
Ranch Hand
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I use IllegalArgumentException and IllegalStateException extensively.
 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • 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.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!