Exceptions or Return Values
-
I'm creating an n-tier application that I want to implement decent error handling in. Its probably best to describe an Example and request comment. The presentation layer is a form to Redeem a coupon. The user enters into the form details and has a submit button. The business logic layer (Redeem function) will do some basic checking such as the coupon hasnt been validated already or cancelled or expired and if OK will perform the status chnage to indicate that it has now been redeemed. The data access layer consists of simple getstatus and changestatus functions to call stored procedures. In this example the data access or business logic layers could fail as a result of a whole host of items - such as SQL problems or invalid status for the action. If I went with the approach I'm more familar with which is from a VB6 background - I could return different codes from the functions and track in the calling function and control the actions as a result of these different problems. I'd probably set up a enumeration in a interface file used by all components - so that I dont just use magic numbers but that the return code is either success or a code indicating cause of the problem. But I'd still need some exception handling to deal with all other eventuallities. The more .NET approach may be to create custom exceptions for the application. And throw these errors instead of return codes. This would allow the exceptions to bubble to a layer where they are dealt with. The functions would then return either a success or throw an exception. Only small simple functions that only require a success or failure would possibly use return code values other than success. This would require some custom exceptions created for situations like ItemDoesntExist and InvalidStateTransition but I could see this being a nice approach as all functions would have exception handlers and a pretty standard template would be used by deafult on all functions with addition of catch statements for more specifics to be dealt with. In above example I'd have a different form that would be called if something didn't exist to if the action was invalid because say the status' were incorrect. This is why I'd need specific reasons as to why something had failed. Any thoughts on these two approaches ? I could use either.....
-
I'm creating an n-tier application that I want to implement decent error handling in. Its probably best to describe an Example and request comment. The presentation layer is a form to Redeem a coupon. The user enters into the form details and has a submit button. The business logic layer (Redeem function) will do some basic checking such as the coupon hasnt been validated already or cancelled or expired and if OK will perform the status chnage to indicate that it has now been redeemed. The data access layer consists of simple getstatus and changestatus functions to call stored procedures. In this example the data access or business logic layers could fail as a result of a whole host of items - such as SQL problems or invalid status for the action. If I went with the approach I'm more familar with which is from a VB6 background - I could return different codes from the functions and track in the calling function and control the actions as a result of these different problems. I'd probably set up a enumeration in a interface file used by all components - so that I dont just use magic numbers but that the return code is either success or a code indicating cause of the problem. But I'd still need some exception handling to deal with all other eventuallities. The more .NET approach may be to create custom exceptions for the application. And throw these errors instead of return codes. This would allow the exceptions to bubble to a layer where they are dealt with. The functions would then return either a success or throw an exception. Only small simple functions that only require a success or failure would possibly use return code values other than success. This would require some custom exceptions created for situations like ItemDoesntExist and InvalidStateTransition but I could see this being a nice approach as all functions would have exception handlers and a pretty standard template would be used by deafult on all functions with addition of catch statements for more specifics to be dealt with. In above example I'd have a different form that would be called if something didn't exist to if the action was invalid because say the status' were incorrect. This is why I'd need specific reasons as to why something had failed. Any thoughts on these two approaches ? I could use either.....
I think that it would be better to use Exceptions as the .NET framework itself uses it. "I think there is a world market for maybe 5 computers" Thomas Watson, chairman of IBM, 1943 "There is no reason anyone would want a computer in their home" Ken Olson, chairman & founder of Digital equipment, 1977 "This 'telephone' has too many shortcomings to be seriously considered as a means of communication. The device is ingerently of no value to us." Western Union internal memo, 1876 "640 K ought to be enough for anybody." Bill Gates, 1981 "Computers in the future may