 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2008java exception handling
i was arguing with my manager about whether it's better to throw exception from a service that im developing or to give the user returned value. My supporting points are: 1-thowing exception is much mostly than returned value in term of performance. 2-in returned value way the user can customize the behavior of the system as he like and he would have clear view of the service result. 3-with respect to the user requirement he doesn't really need a returned value or exception from the service. my manager supporting points: 1-the service should be general so in future if somebody want to be informed by the result of the service we don't have to modify it. but infact if we consider all the assumption we will delf into hunders of assumptions and if this is nessary the returned value is better way than throwing exception. im very sorry for my long plah plah plah any one have a comment. Note: code in java > i was arguing with my manager about whether it's better to throw > exception from a service that im developing or to give the user [quoted text clipped - 13 lines] > of assumptions and if this is nessary the returned value is better way > than throwing exception. I think exceptions has a couple of advantages over return value error indication: 1) You can force the programmer to deal with it by making the exception checked. 2) If the exception is not to be handled by the calling method, then exceptions is much easier to get bubbling up through the call stack than return values. And performance should not be a problem. Exceptions should be an exception ! :-) Arne > > i was arguing with my manager about whether it's better to throw > > exception from a service that im developing or to give the user [quoted text clipped - 30 lines] > > - عرض النص المقتبس - >> And performance should not be a problem. Exceptions should be >> an exception ! :-) >> >> Arne- إخفاء النص المقتبس - >> >> - عرض النص المقتبس - Say what ? Arne Arne Vajhøj wrote : >>> And performance should not be a problem. Exceptions should be >>> an exception ! :-) [quoted text clipped - 6 lines] > > Arne That would be: what say  SignatureWojtek :-) > i was arguing with my manager about whether it's better to throw > exception from a service that im developing or to give the user > returned value. My supporting points are: > 1-thowing exception is much mostly than returned value in term of > performance. The impact of try-catch blocks when they are not used has become negligible and the performance impact is not terrible when they are used. But any performance gained is on the order of several machine cycles, which is not enough to impact such a major architecture decision. > 2-in returned value way the user can customize the behavior of the > system as he like and he would have clear view of the service result. But values may be in imperfect states. A lazy user might not realize that failures could happen and important code could blow up in his face. > 3-with respect to the user requirement he doesn't really need a > returned value or exception from > the service. If something is wrong, he needs to know. Period, full stop, end of story. > my manager supporting points: > 1-the service should be general so in future if somebody want to be [quoted text clipped - 3 lines] > of assumptions and if this is nessary the returned value is better way > than throwing exception. How so? I sense some C or C++ assumptions coming into play here. 2. An exception can force the user to deal with the error. The user is often in the best seat to decide whether or not he should repair the situation or forcibly terminate. 3. Exceptions can provide finer granularity control over errors. Imagine if Class.getMethod simply returned null instead of throwing an exception. It would be difficult to tell if it was because the method didn't exist or if it was merely insufficient access, the difference between which may be important. 4. Hijacking the return values makes chaining operations difficult. Class.forName(className).getMethod(name, args); is a somewhat common idiom for code needing reflection. Should forName return null on error, I would have to check for nullity first. You also have not fully described what the circumstances are. In general, the Java API often provides a good role model to follow. The only times where it uses return values is where failure is not exceptional, e.g., adding a method to a Set. > im very sorry for my long plah plah plah The proper term I believe is "pontification." > any one have a comment. One nit: try to use some more capitalization and spacing between paragraphs. It's easier on eyes. SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > [several good arguments for exceptions] ... > You also have not fully described what the circumstances are. In > general, the Java API often provides a good role model to follow. The > only times where it uses return values is where failure is not > exceptional, e.g., adding a method to a Set. Joshua shows that exceptions are often, but not always, the best idiom for things that seem to go either way. Stepping back, Joshua's excellent advice is rooted in a perspective that distinguishes "in-line" returns from "out-of-line" conditions that belong to exceptions. This part of domain analysis is fuzzy at times, no question. What really is an "in-line" result in the problem domain? One must factor predictions of which idiom will prove more troublesome to maintain in the future. Notice that Joshua's answer is also grounded in the notion of operational usefulness - what mechanism makes it easier to keep a system running in the field? There is a conceptual ground and a pragmatic basis that both argue for his conclusions. The consideration of future use is the hardest but also most important part of planning an architecture. With a Really Useful Application, the operational phase is the longest and most critical part of the life cycle. SignatureLew > > i was arguing with my manager about whether it's better to throw > > exception from a service that im developing or to give the user [quoted text clipped - 61 lines] > Beware of bugs in the above code; I have only proved it correct, not > tried it. -- Donald E. Knuth ok I agree with you Arne and Joshua that exception forces the programmer to deal with the result but one thing I have to clarify, is that this services is provided to a department where they don't really care about the result of this service at business level. In fact it concerns the service provider himself who needs to know when some action is happening in the this department to perform some action useful for him. Anther thing i have to mention is that we have more than 1700 expected daily transactions on this service so we may give the performance factor more attention even its negligible at the level of single transaction. exception involves extra code and processing while in reality we don't need even any returned value from the service. alot of Thanks for u. > ok I agree with you Arne and Joshua that exception forces the > programmer to deal with the result but one thing I have to clarify, is [quoted text clipped - 3 lines] > some action is happening in the this department to perform some action > useful for him. How does this affect the issue of whether to use exceptions? > Anther thing i have to mention is that we have more than 1700 expected > daily transactions on this service so we may give the performance > factor more attention even its negligible at the level of single > transaction. How does this affect the issue of whether to use exceptions? > exception involves extra code and processing while in reality we don't > need even any returned > value from the service. How does this affect the issue of whether to use exceptions? Exceptions are not "extra" code. "Extra" code is code not needed. Exceptions are code that is needed. Therefore, not "extra". What is this laziness on the part of programmers, that they do not wish to code the logic the problem at hand requires? Correctly used, exceptions help the programmer of the application. They aren't there to help the user, except indirectly in that the user will never see the crashes prevented by the use of exceptions. So the question with exceptions is whether you want to prevent the user from experiencing program crashes. If you do wish to prevent the user from experiencing program crashes, then exceptions are a powerful tool for that. SignatureLew > ok I agree with you Arne and Joshua that exception forces the > programmer to deal with the result but one thing I have to clarify, is [quoted text clipped - 3 lines] > some action is happening in the this department to perform some action > useful for him. Does not change anything. > Anther thing i have to mention is that we have more than 1700 expected > daily transactions on this service so we may give the performance > factor more attention even its negligible at the level of single > transaction. 1700 daily transactions is absolutely nothing when we talk overhead of exceptions. If we assume that 1 million exceptions per second is 100% load, then 1700 exceptions per day is approx. 0.000002% extra load. I think you can live with that. > exception involves extra code and processing while in reality we don't > need even any returned > value from the service. I think you need it. Arne On Tue, 1 Jan 2008 03:30:42 -0800 (PST), polaris <smarto59@hotmail.com> wrote, quoted or indirectly quoted someone who said : >any one have a comment See http://mindprod.com/jgloss/exception.html#STATUSCODE It should be uploaded within about 15 minutes. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On 3 يناير, 11:31, Roedy Green <see_website@mindprod.com.invalid> wrote: > On Tue, 1 Jan 2008 03:30:42 -0800 (PST), polaris > <smarto59@hotmail.com> wrote, quoted or indirectly quoted someone who [quoted text clipped - 9 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com ok thank you for everybody by his name contributed under this thread I got the idea now. The idea I got is that with respect to our service nature where it should throw an exception if it doesn't find any related record for the input values in DB. Actually this the common case for all the 1700 service call. At most may be there are 10 of 1700 cases where it finds records corresponding to the input values and therefore it won't throw exception. As I conclude from the following statement in Roedy link http://mindprod.com/jgloss/exception.html#STATUSCODE Exceptions should be exceptional. If there are 50/50 odds of either status, you should use a status code. There is an extra overhead to catching an exception. It's better to use status code for our case. and this is what Arne said as well. On Thu, 3 Jan 2008 11:28:32 -0800 (PST), polaris <smarto59@hotmail.com> wrote, quoted or indirectly quoted someone who said : >As I conclude from the following statement in Roedy link >http://mindprod.com/jgloss/exception.html#STATUSCODE [quoted text clipped - 3 lines] >It's better to use status code for our case. >and this is what Arne said as well. I have revised that paragraph to read: Should you report problems with a status code returned from a method or with an Exception? The C-style is to use status codes. There is nothing that says the caller has check a status code. Programmers are lazy and don't bother to check return codes. No error or warning is generated. If the caller of the caller is the proper place to handle the exception it takes futzing to propagate the information up the chain. Exceptions should be exceptional. They are for errors, things that are not supposed happen. EOFException is a special case. It will happen at most once per file. If there are 50/50 odds of either status, you should use a status code. There is an extra overhead to catching an exception. Don't use Exceptions to return common place data or status. A rule of thumb might be if a method returns an error more often than 1 in 10, use a status code instead of an Exception to report the problem. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.