Home/ Questions/Q 6120607
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T15:41:15+00:00

I am coding some kind of a WCF service. most exceptions are caught in

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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!

    • 0