What ends up happening ...

Post #143,883 by bluke 2/29/04 1:33:07 AM Reply	What ends up happening ... is that you have reams of code catching exceptions, wrapping them in some new exception and throwing them. What value have you added by wrapping the original exception 10 times? Take a typical example. Your low level data layer fails getting data from the database for some reason (e.g. because the database is down). In most cases there is nothing that you can really do with this exception except log the error and present an error message to the user. What value is there in making all the intermediate layers catch the exception wrap it in a different exception and throw the new exception? What value have you added? The bottom line is that the topmost gui layer should catch the exception and present the error message whether or not you wrapped the exception 10 times or not.
Post #143,964 by dshellman 3/1/04 7:38:49 AM Reply	Re: What ends up happening ... I think 10 times is a little excessive. And I think the database access (specifically SQLException) is also a poor example, as it's debatable whether it should have been a checked exception in the first place. Dan
Post #143,989 by tuberculosis 3/1/04 12:18:27 PM Reply	Re: What ends up happening ... [i]I think the database access (specifically SQLException) is also a poor example, as it's debatable whether it should have been a checked exception in the first place.[/i] OK but its debateable whether any exception should be a checked exception. For instance, InputStream - a fully abstract class - insists than any method may throw an IOException which must be caught (its checked). Yet there are instances of InputStream that do not throw this exception - yet the programmer is still burdened with writing code to handle exceptions that will not be thrown. This is a fundamental problem with static typing and hard wired method signatures. InputStream in = new StringBufferInputStream(buffer); int c = -1; try { c = in.read(); } catch(IOException ex) {} // won't really throw Of course, you can't exactly know that in is going to reference something that won't throw. My biggest complaint though is that checked exceptions leak concerns of implementation into the interface. This results in very brittle systems. The tree of research must from time to time be refreshed with the blood of bean counters. -- Alan Kay
Post #144,018 by bluke 3/1/04 3:02:14 PM Reply	You didn't answer the question ... What value is there in wrapping exceptions? 10 was obviously an exaggeration. What do you think should have been an unchecked exception?
Post #144,088 by dshellman 3/2/04 9:13:43 AM Reply	Re: You didn't answer the question ... Wrapping exception is used to create a facade to the next layer. So, since SQL exceptions are checked, I can do one of two things: I can wrap them and rethrow them as application-specific checked exceptions, or I can rethrow them as unchecked exceptions. For SQL exceptions, I've seen both. Personally, I usually wrap them in checked exceptions because I like to associate a prettier error message with them as close to where it happens (I have more contextual information at that point). Then, I have a simple application-specific checked exception that the higher layer (say the presentation layer) can deal with in a generic, simple fashion (in some cases, the higher layer may not even need to know anything about the exception because it contains enough information for display purposes, but that's dependent upon the application type and how it's designed). I approach unchecked exceptions in this way: if it's a programmer's error (i.e. a null pointer exception or something like that), an error (i.e. out of memory), or something that can't be handled and dealt with at a lower level (because the contextual info isn't helpful, or it doesn't make sense to), then using unchecked exceptions works well. However, if it's a application exception, such as bad input from the user, database going down (and this one can go either way...it depends upon the interface to the user), etc. then checked exceptions are nice because they can usually be handled nicely by the upper layer. Hope that answers your question. Dan
Post #144,187 by bluke 3/3/04 5:05:16 AM Reply	A number of comments 1. in any given layer the exception can occur far down the call stack. Especially if you write short methods you may be far down the call stack when you catch and wrap an exception. This means that every method above you in the call stack needs to do something with the exception, probably just throw it, clearly a waste. 2. If each layer only throws 1 exception you lose information. The UI may want to display different pages depending on the exception. For example, if you receive a licensing exception the UI may want to display a licensing page, while a validation exception may redisplay the form. By wrapping the exceptions in a general exception youy make it hard for the client to figure out what really went wrong. The client then has to go and look at the wrapped exception and get the cause. 3. Many times you have a number of layers and they just wrap the exception without adding any new information.

Welcome to IWETHEY!