Re: web service error handling design issue
I excluded "being ridiculously wasteful or using poorly designed algorithms". Of course, we need to be careful but not in the way we used to fret over optimal coding. When specifying an for-loop counter, how many people load the size of an ArrayList into a local variable rather than call size() each iteration (I do but most people don't). - Original Message - From: "Dan Armbrust" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 5:47 PM Subject: Re: web service error handling design issue > > > > > >programmers no longer need to worry about performance. In fact, we stopped > >worrying about performance once we abandoned C++ for Java! > > > > Speak for yourself... Maybe you work in a world where the datasets are > small, and hardware budgets grow quickly > > I remember digging into a third party package that we were using - they > had recently ported from c to java, and the performance of the new > version sucked on certain operations. Examination of the code revealed > that there was one method that got its result by opening a random file > reader on a 200K file, and finding the appropriate bits. The algorithm > called this method several hundred times per operation. A simple change > to a hashtable based approach with a one-time read of the file resulted > in an operation that ran about 1000 times faster. Multiple that by the > 500,000,000 times I needed to call that method, and we start talking > years instead of hours to process the same data > > Dan > > > > >
Re: web service error handling design issue
programmers no longer need to worry about performance. In fact, we stopped worrying about performance once we abandoned C++ for Java! Speak for yourself... Maybe you work in a world where the datasets are small, and hardware budgets grow quickly I remember digging into a third party package that we were using - they had recently ported from c to java, and the performance of the new version sucked on certain operations. Examination of the code revealed that there was one method that got its result by opening a random file reader on a 200K file, and finding the appropriate bits. The algorithm called this method several hundred times per operation. A simple change to a hashtable based approach with a one-time read of the file resulted in an operation that ran about 1000 times faster. Multiple that by the 500,000,000 times I needed to call that method, and we start talking years instead of hours to process the same data Dan
Re: web service error handling design issue
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: 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: > 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: axis-user@ws.apache.org > 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
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: > 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: axis-user@ws.apache.org > 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 >
Re: web service error handling design issue
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: 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: axis-user@ws.apache.org 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: 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 explanat
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: axis-user@ws.apache.org 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: 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
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: 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
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
