Rather than obfuscate, extra wrapped exceptions should add clarity. It is not expensive to add exceptions nor is there any benefit to handling exceptions as quickly as possible. Don't get exceptions confused with system interrupts. Once an error has occurred, we are no longer concerned with performance but with proper handling of the condition. Furthermore, unless we are being ridiculously wasteful or using poorly designed algorithms, performance improvements are down to hardware these days. With 16-core Opteron systems at affordable prices and RAM measured in tens of GB, programmers no longer need to worry about performance. In fact, we stopped worrying about performance once we abandoned C++ for Java!
Jeff ----- Original Message ----- From: "James Taylor" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, June 02, 2005 4:39 PM Subject: Re: web service error handling design issue Sure there's different fixes for different situations but at the end of the day is it not better to deal with the exception as quickly as possible so it doesn't get obfuscated in too many extra wrapped exceptions. Also is it not "expensive", to a degree, to create exceptions? By this I'm wondering that is it not better to try and lessen the overhead on resources on the server. Quoting Jeff <[EMAIL PROTECTED]>: > I agree entirely. I took it as read that error conditions in Java are known > as exceptions :-) > > > Jeff > > > > ----- Original Message ----- > From: "Ebert, Chris" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, June 02, 2005 1:36 PM > Subject: RE: web service error handling design issue > > > > A (hopefully short) two cents: > > 1) Usually, I prefer to propagate exceptions rather than error codes. > Exceptions really can make application flow simpler. I agree that > 'cooking' the exception is good: the topmost layer that has an > additional useful detail should add it; also, it's often nice to wrap an > exception to provide a consitant interface (wrap an SQLException in a > FooSubsystemException so different implementations can use a database, a > file system, etc.) Error codes are good when the alternate behaviour > isn't really 'exceptional' -- happens, say, 30+% of the time anyway. > 2) That said, when passing exceptions -- particularly chained ones -- > over a remote interface you want to create an exception class > specifically for the interface and only give it basic types as fields -- > no chained exceptions here. This is because you don't want to have all > the server exceptions in the client jar. Axis handles this somewhat > gracefully (you get a null): RMI throws it's own exception if a class > isn't available upon deserialization. This lets the client recognise a > server fault, get some information back about it and decide what to do. > > Hope that was helpful :) > > Chris > > > > -----Original Message----- > From: Jeff [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 02, 2005 8:41 AM > To: [email protected] > Subject: Re: web service error handling design issue > > Life is never that simple, James! Academics are prone to produce bland > generalizations and are notorious for being out of touch with reality, > though I suspect that this is due to a few loonies giving the rest a bad > name! Clearly, most academics do a great deal of invaluable work for > which they have my deepest gratitude. > > I once heard that a university professor who claimed that it wasn't > possible to write more than 10 lines of fully debugged code per day. > I've been developing software for 25 years and if my output was anything > like that I'd have gone broke years ago! Only a few months ago at a Java > Users Group meeting I overheard an academic stating with conviction that > "If you have to use a case statement then you didn't do your OOD > properly." -- yeah, right...cretin. > > To answer your question: in any software system, at any point between > where an error occurs and where the outer-most calling code needs to > know about the error, it is potentially appropriate to cook the error. > In many circumstances it is inappropriate for calling code to know the > simple, raw reason why an error occurs. For example, suppose that during > some web service method call a required file was discovered to be absent > from its expected location on a disk. Should you tell the web service > client about this? Most likely not, because that piece of information is > unlikely to be meaningful to the client. Instead, code much closer to > error needs to figure out the consequences and throw an interpretation > up the chain where other code might be able to do something to fix the > problem (e.g. create a new file from default values and retry) or to > rethrow a more intelligible error. > > Unfortunately, cooking errors is something that often doesn't happen > because too many programmers have higher priorities and finite > deadlines. How many times have you seen a ClassCastException and > wondered which class the code was attempting to cast to? One poorly > handled error can result in a great deal of wasted time, collectively > over thousands of people. > > Also, please note that there are many types of error and you need to be > aware that during software development we see errors (that tend to be > uncooked) that arise through flaws in the logic of the software and will > go away once the code has been debugged but, as an aid to development, > we might want to cook them if they are not immediately resolvable. As I > said, reality is rarely simple, at least not when human beings are > involved. > > BTW, this is not a design issue, it's about writing good software. > > > Jeff > > > Between the question and the answer, all too often, lies pure hell > > > > ----- Original Message ----- > From: "James Taylor" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, June 02, 2005 10:22 AM > Subject: web service error handling design issue > > > Hey, > another design issue on a different note. In our college course we a > told to > propogate error up to the top layer/controller and deal with them > appropriately. > What's the best way to deal with errors in the case of web services? > Should > I > catch the exception and return an appropriate fault node/code and deal > with > this in the client code or catch the error at the service provider top > level > and return an appropriate explanation? > Just looking for ideas and what way is it done in industry. > Thanks to anyone that gives my the time to answer, > James. > > > -- > Between the question and the answer lies free will > > -- Between the question and the answer lies free will
