views:

93

answers:

4

What exceptions can be thrown from a WCF client?

I usually catch CommunicationFaultedException, CommunicationException, TimoutException and some other but from time to time new ones occur, e.g. most recently QuotaExceededException

There is no common base to catch (except Exception) so does anyone have a complete list?

+1  A: 

Why would there be a complete list? This isn't Java.

Why do you want to catch an exception you don't understand? How would you "handle" it if you don't know what it means?

Go ahead and catch exceptions to log them, if you like, but you should rethrow after you catch it. Let the exception propagate up to some code that knows what to do with it.

John Saunders
Not very helpful. Unfortunately WCF is designed such that clients generally need to catch CommunicationException and TimeoutException, and abort the channel, as described in the article linked from daft's more helpful answer. Poor design as the using statement can't be used to perform cleanup, but we have to live with it. The interesting question is whether other exception types like QuotaExceededException require this special handling - I suspect not but am not sure.
Joe
The intention is not to catch them all. I just want to know which ones to expect so I can decide what to do about them. Since I didn't know about QuotaExceeded it was caught in my application top level catch which seems like the wrong place to handle wcf configurations problems.
adrianm
If you don't know about them, then you don't know what to do about them, so leave them alone!
John Saunders
I thought the whole idea of stackoverflow was to learn about things I don't know about so I can (maybe) do something about them.
adrianm
@adrianm: learn this. You cannot "do something" about most exceptions. The correct action to take in almost every case is to do nothing at all. If you cannot actually **fix** the problem, then you should do nothing more than log the exception or add additional information. Beyond that, I promise you that, contrary to expectation and popular belief, you are far better off doing nothing at all.
John Saunders
+1  A: 

This might be a good place to start: Expected Exceptions.

daft
Thanks. Unfortunately that page only talks about the ones I already catch (Communication and Timeout) and the ones I don't want to catch (InvalidOperation, Argument etc).
adrianm
A: 

Just thinking outloud... one solution could be:

  1. Add the list of exceptions(and exception casting) in your Custom exception class; for instance CException.
  2. As soon as you catch an exception in your Exception block, throw another exception into your CException class. For instance like following:

    catch(Exception ex){throw new CException("An error occured", ex);}

See this example.

KMan
Why is this a good thing to do? Leave the exception uncaught and it will propagate just fine without your custom exception.
John Saunders
@John: I was thinking around, catching the exception in one central location and then cast it according to the type(list) of exceptions available.
KMan
@KMan: again, why would this be a good thing to do?
John Saunders
@John: ... it might help in case where OP wants to **not** to break the application flow. Somehow prevent the *propagation* till the last end.
KMan
@KMan: again, I've never seen a use for this. It looks like needless complication, and worse, something that will confuse someone new to WCF and even to exceptions.
John Saunders
@John: Above the top of my head, how about a user performing an action(database transaction for instance), and get an exception, now - there could be scenario - that rather than letting the exception propagate to the tail(and losing all context), you might just want to "try again" with some different query data, using "same" object state/context. Well, you can also maintain context snapshots-points to redo the action; but... I am sorry I am unable to understand why this would be a bad practice (as your comment sounds). (0:
KMan
A: 

The CommunicationException is the base exception for all WCF exceptions. If you catch that, you catch everything WCF related.

See the MSDN docs for CommunicationException. It will also nicely show a list of all derived classes, e.g. all more specific exceptions that can occur in WCF - quite a long list!

marc_s
Nope, QuotaExceededException and TimeOutException are not derived from CommunicationException
adrianm
@adrianm: well, the TimeOutException is a general exception - *not* WCF specific - so it's obvious it's not derived from CommunicationExecption. I'm stumped about the QuotaExceededException though - thanks for pointing that out!
marc_s