I want to catch all unhandled exceptions thrown in a remote object on the server and log them there before I translate them into some custom exception so that specific exceptions do not cross the client/server boundary.
I think I have to use a custom channel sync, but can anyone confirm this and/or have any other advice to give?
I would use the Microsoft Enterprise Library Exception Handling app block -- it lets you handle errors and convert specific types of exception to a different type of exception before rethrowing to the client.
After finding Eliyahu Baker's helpful blog post and reading chapter 12 of Rammer's Advanced .NET Remoting I wrote a custom channel sink that does what I want. This intercepts any exception and logs it locally before sending it on to the client.
Ideally, I'd like to log the exception and raise a more generic one for the client, but I haven't cracked that nut yet.
Related
I know that we can use FaultException and FaultContract to catch these exception?
Is there any other way to (Except FaultException/FaultContract) catch specifically these two Exception (Transport and Communication)?
According to the Microsoft documentation, transport and communication errors are handled by the CommunicationException class.
Communication errors occur when a network is unavailable, a client
uses an incorrect address, or the service host is not listening for
incoming messages. Errors of this type are returned to the client as
CommunicationException or CommunicationException-derived classes.
The following provides a good overview of the three categories of WCF errors:
Communication Errors
Proxy/Channel Errors
Application Errors
https://learn.microsoft.com/en-us/dotnet/framework/wcf/wcf-error-handling
There is an asp.net based backend, where I use wcf services to communicate with client, which is a WPF application. When the data comes back from server, and during deserialization, it throws a communication exception. Here is the exception:
Exception thrown: 'System.ServiceModel.CommunicationException' in mscorlib.dll
Additional information: Error in deserializing body of reply message for operation 'AutoImportGetProtokolls'. The input source is not correctly formatted.
Source: http://pastebin.com/ZtUxYNUm
Here is a photo about the exception: https://www.dropbox.com/s/5araq9oajhrhrty/communicationexception.png?dl=0
I have another application based on silverlight, and when I call the same service, the exception does not come. After I start the WPF application the exception comes every time for first service call, after that it comes "randomly" (I could not find any logic when)
What I have tried so far but did not help:
-I used a DTO (data transfare object) class instead of generated one by entity framework. (sp_AutoImport_GetProtokolls_Result)
-Deleted the "out ErrorCustomModel res" parameter from service.
-Many source in google said that I should take a look for webconfing, and increase the property value of readerquotas. Here is the relevant part of webconfig: pastebin.com/e4ZpQsMK
Thank you guys, every hint are welcome.
Best Regards,
Norbert
I have been looking at the MSDN documentation and I cannot seem to work out what the difference is:
SmtpException Class
Represents the exception that is thrown when the SmtpClient is not able to complete a Send or SendAsync operation.
SmtpFailedRecipientException
Represents the exception that is thrown when the SmtpClient is not able to complete a Send or SendAsync operation to a particular recipient.
I can't find any information in the documentation to what "operation to a particular recipient" actually means.
Aside
The reason I ask is because I am trying to catch certain exceptions in my client application and execute different methods accordingly.
For Example:
If server is down I would like to leave the file where it is
If send address is invalid I would like to move the file to "Failed" folder
The source for SmtpClient.cs indicates that SmtpException is used for exceptions trying to get to the point of sending the message. SmtpFailedRecipientException is for an error reaching the client (but everything on the server worked fine).
I am currently doing some research on how to handle exceptions and let the client know in a winforms app which calls a WCF service (Self-hosted in a windows service). What is the best way for this? A couple of questions:
1) If I let an exception propagate, it'll come up on the client side.
2) What's the best way to catch the exception on the client side? Is it:
catch (FaultException<T> fault) { }
(Empty catch block just for demo purposes). Or is there another way?
You will need to put each of your calls in a try{}catch{} block since that is where it will be propagated from on the client side, possibly encompassing some of the possible exception handing in some sort of proxy to hide the WCF specific handling.
Using exception shielding you can also specify custom FaultExceptions and decorate the method with attributes to allow that exception to be sent down to the client. That way you can be a little more intelligent when the exception arises.
e.g.
try{
... call service
}catch(FaultException<TimeoutFault> ex){
.. try one more time
}catch(FaultException<InvalidSelection> ex){
... show message to user from ex.Details.InvalidProperty
}catch(FaultException){
... handle
}catch (CommunicationException ex){
... remember this is WCF so the call itself might fail
}catch(Exception ex){
... handle
}
Id reccomend reading http://blogs.msdn.com/b/pedram/archive/2008/01/25/wcf-error-handling-and-some-best-practices.aspx as it has a few good tips/
You should always at least catch CommunicationException, of which FaultException (and others) derives from. Generally you will only get FaultException during development of your service (set IncludeExceptionDetailInFaults to get better faults while debugging). CommunicationException can occur when the service is not running, among many other reasons. You may want to read this MSDN article for more information about error handling in your WCF service.
I noticed that if you do a throw new InvalidCastException for example, the channel state on the client side is faulted. But if you throw new FaultException, the channel state on the client side is opened.
By curiosity, what is the reason why one faults the channel and the other doesn't?
The FaultException is a special case in WCF. It's meant to indicate that something happened on the service side that was an error, but at the same time, not fault the channel. This makes sense, given you can embed this information into the contract using the FaultContractAttribute to expose what can be expected from a contract.
Other exceptions are not really translatable in the WS world. Exceptions are a technology-specific abstraction, and each technology stack has a different representation of that abstraction (or in some cases, none at all).
That being said, when an exception that is not a fault exception is thrown on the server side, it is seen as catastrophic by the WCF runtime, and the channel must be faulted, as it is not known if you can proceed or not.
However, using FaultException, it implies you have some foresight into the conditions around why it was thrown and whether or not the underlying channel has been impacted or not.