I am coding some kind of a WCF service. most exceptions are caught in the BL implementation and handled there. Each of my API's return type is a class (named - "result") containing error code, error message and success boolean.
When exceptions are handled, this class is updated accordingly and in the end is sent back to the client. Some of the exceptions are off-course, unhandled. Currently, I am wrapping each of my BL calls from the service layer with a generic try-catch so I can catch every unhandled exception and create a generic "result" class with a generic failure message, error code and success=false.
Is it a good way to handle exceptions or should I let unhandled exception to be thrown by the service to the client? You can assume that the client can't use the data from the exception so it won't benefit from the extra information contained in the exception.
We can use FaultException &/or FaultContract (in System. ServiceModel namespace) to these exception details to the client.
Fault exceptions are exceptions that are thrown by a WCF service when an exception occurs at runtime -- such exceptions are typically used to transmit untyped fault data to the service consumers.
With the service running, right click the project that will contain the WCF client proxy and select Add > Service Reference. In the Add Service Reference Dialog, type in the URL to the service you want to call and click the Go button. The dialog will display a list of services available at the address you specify.
Check out Exception Shielding.
This is a process where exceptions raised by the service, are mapped to fault contracts according to rules you specify in a configuration file. This saves a lot of donkey work with try/catch blocks.
Here is one post to help you out:
In general though - faults will fall into 3 categories:
1) Client error - the client has tried to do something not permissable, so it needs to know about it. E.g. Failed to set a mandatory field. - Return specific message explaining fault.
2) Business error that doesn't affect the client. An error that is considered normal operation, e.g. Payment Authorization check failure. Either hide from client completely, or return some message: "Error performing request: Please try again later..."
3) System error - Unexpected - not normal operation: Replace with generic message: "System Error: Call Support"
In all cases though, the key thing is you remove the stack trace, especially if it's a public facing service.
With shielding you would have 3 Fault Contracts covering the above scenarios, and set the text appropriately in the Shielding configuration.
Be advised, you generally want shielding turned off during development as it makes it a right pain to debug the system!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With