Exception Handling in Business logic

Hi,

Following questions are related to the business logic:
1. What way is the best to pass the error message and error type back to the client/subscriber when the client executing a method on the server/publisher
2. I found few ways to do it:
a. Traditional way of return error type ( like C)
For example:
public function (ByVal id as integer) as errorType
errorType contains: Invalidid, NotAllowed, etc
b. Throwing an exception to the client/subscriber.
c. Creating an event that fire when the error occured
Can anybody please tell me which way is the best Is there any better way

Thank you.

Answer this question

Exception Handling in Business logic

William Lowers
Hi All,

Thanks for the answer.
I found out somewhere from the internet that event in .Net is actually pretty expensive as well.
Does anybody has a good guideline for designing the exception in the business logic
What kind of exception should be thrown Shall I create a custom exception for each error

Thanks
Pom Figueroa

Hi

It will depend the amount of information that you need to pass to the client and the frequency of those errors.

1) If the function needs to return if it was succesful or not you can use a boolean return, we usually do this logging the error (or exception) details into a log file. Sometimes you can return a more complex structure, detailing error number and a description.

2) If you are developing a control or a library that you need to distribute to third parties you can use exceptions for errors related with configuration or wrong data format (or any other unexpected situation). Sometimes you can use events but this is less common.

3) If your component detects an unusal error you can raise an exception, remember that they are expensive so do not base your business logic on exceptions.

My recommendation is to go for the first option, use log files for details.

Best regards
spree

I would say events. They are best practice I believe and no one needs to know anything about anyone else, except for the subscription of the event, and when the event is risen, all subscribers are notified and handles the error in its own way rather than checking a class/whatever to see if there was an error on the last call/execution of request.

You could throw an exception but could be expensive sometimes but it is also recommended to throw an appropriate exception at the time - I would probably throw an exception if something fatel happened (like, index out of bounds or something, i dont know) - but dealing with events is probably stronger in my opinion as your just notifying all subscribers rather than just the caller where the exception would be thrown.

Just my point of view :-)
ReneeC
It is usually a bad idea to remove information about an exception, you'll have a tough time troubleshooting what really went wrong. That kills option "a". The client almost always needs to know that a specific operation in the business layer failed so it doesn't attempt to proceed in a multi-step operation. That kills option "c".

You have two options on passing an exception back to the client. If there is a meaningful way for a client to recover from a specific failure, you'd want to throw your own exception with the original exception embedded as the InnerException. That allows the client to filter for that specific failure and take corrective action. If no such corrective action is available, just throw the original exception.
Exception Handling in Business logic

Answer this question