I have silverlight application which uses WCF for database operations. Using Fiddler I am able to tamper the parameters required for a particular method used in WCF and getting an exception "a:DeserializationFailedThe formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:parameters. The InnerException message was 'There was an error deserializing the object of type........". My security team does not like this and saying it is exposing the real exception. Is there any way to handle this type of exception and show some user define message? If yes then please provide the complete sample. I went through so many articles in internet but none of them is having complete solution.
You need to implement a custom error handler. See
http://msdn.microsoft.com/en-us/library/ms599828
For lots of reference details and this
http://www.neovolve.com/post/2008/04/07/implementing-ierrorhandler.aspx
For an example that implements (in a basic, but instructive way) exactly the exception shielding behaviour you are looking for.
Related
Strangely I can't find anything on google for this. When doing regular exception stuff you'd create a MyCustomException : Exception and I assumed the same applied to ExceptionFaults.
When someone calls my service with an invalid api key, I wanted to throw an InvalidApiKeyExceptionFault. I can't seem to find an example online of how to set this up and have the client be able to catch it (presumably an attribute somewhere to include it into the WSDL).
Any suggestions where to look, or am I trying something that's not possible?
You should use FaultException<TDetail> and put your specific information in the serializable TDetail type.
Your service contract should have a fault contract specifying the TDetail type.
This technique enables you to communicate error information in an interoperable way, including to clients that know nothing about .NET exceptions.
If for some reason you don't want to use fault contracts, you could consider using the non-generic FaultException, and communicate additional information about the error in the fault reason and/or fault code / subcode.
I am thinking in use some exceptions to from service to client.
I am thinking for example in this case. The client try to insert a register in the database. This register has a value for e filed that exists in the database, and how it has a unique constraint, when I do the savechanges I get an updateException.
I am thinking to use exceptions (faultException) to warn to client of the error, and use a custom class to send to the client the actual data of the register, so in this way the client does not to make other query for the register.
However, in this link, it says that exceptions only should be used in development, no in production, so, without exceptions, how could I do what I want to do?
Perhaps I could use a custom class, that have one list property for each type of entities, and a property bool, that indicates if the operation is right or wrong, other property with an arbitrary code to indicate the type of error... etc. This is a good alternative?
In summary, really is better avoid exceptions in production? how I could communicate to the client errors from the service?
You have 2 options:
Throw exceptions and return WCF faults
Attach error information to you return objects
I personally favour throwing exceptions and returning WCF faults. I dont like the idea of attaching error information to return objects, I feel it violoates object oriented principals. For example a field called 'ErrorCode' has no place on a 'CustomerAddress' object.
I believe that if exceptional circustances arise, then an exception should be thrown. This will also simplfy your code as you wont have to wrap everything in try catch blocks in order to attach error information to your return object. Although you may want to catch unexpected exceptions and then throw a more appropriate exception with a more useful message.
When a method is called on a WCF channel that has been disconnected for some reason, it raises an ObjectDisposedException.
Now is normal operation this should not happen, but if for some reason it did, I would like to be able to handle the exception nicely by showing an error to the user like "An operation failed because the service is not connected".
The problem is I just get a generic disposed exception in my appwide exception handler, so I have no way of determining whether WCF threw it.
to get around this I currently have a wrapper class that simply wraps all service method calls with try/catch and rethrows any ObjectDisposedException's as a custom comms exception that my global handler can deal with. this is a load of boilerplate stuff I could do without though.
Is there any way of determining whether WCF threw the exception?
Cheers
I used to encounter such problem, it seems it's difficult to determine whether the WCF throws exception. You can't use the CommunicationObject.Status for this problem, only when you try to use that channel, it throws exception to tell you that the channel is faulted.
Therefore, I used the way like yours.
I keep getting the 400 bad request if there is de-serialization issue / other errors. If i try to debug by setting a breakpoint in the method that gets called, it does not get hit, if there is a deserialization issue. How do I intercept this and tweak the response to give me more details.
I looked at some articles regarding webprotocolexception but I think the WCF Rest online Template and the starter kit or not the same. Is the starter kit like an add-on to the template?
thanks for your time.
Handling Exceptions in RESTful WCF Services is tough. Deserialization issues are the worst since no user code gets called. The framework handles the Exception and simply returns an error to the caller. There is a way to see those errors though. You have to configure tracing for WCF (via Web.config). Here’s a link describing the process as well as where to find the trace viewer on your machine:
Service Trace Viewer Tool (SvcTraceViewer.exe)
Unfortunately there's no way to tweak that behavior. For other Exceptions, though, you can implement a custom HttpBehavior (or HttpBehavior2 if you're using the REST Starter Kit) with a custom IErrorHandler implementation to handle the Exceptions.
Error 400 means bad request => it is picked up at WCF level and does not even reach the method. So you need to look at the request and if you are passing JSON, fast chance it is in wrong format.
I had a personal project that I implemented in WCF REST and had to battle with this error which was quite frustrating. Also error handling on the server and returning error codes to the client is atrocious since you cannot return text content and all I have is HTTP error code and error description (first line in the HTTP response). I will never ever use WCF REST again as it is a bodged implementation.
I want to log all exceptions (including serialization exception stack traces) in a WCF server to the Windows Event Log (log4net logging would also be acceptable).
What is the easiest way to do this?
Specifically all errors in serialization, in the service itself, etc. Right now I'm using tracing to get serialization errors during development. Tracing was the only way I could find out what object was actually have a problem with serialization. See Quickly finding WCF Serialization/Deserialization Issues for an example of getting the serialization stack trace.
I can handle errors in the service code itself. However, errors in the WCF machinery don't propagate to my service code (like serialization errors).
I don't need to send the errors to the client.
I just want to get the errors into one location (like the Event Log).
Right now (from my research) it appears that the IErrorHandler Interface with some custom code might be the best way to proceed. Will using the IErrorHandling interace catch the serialization exceptions?
Edit:
This may be the answer I'm looking for:
How do I create a global exception handler for a WCF Services?
I'd just like a confirmation that this will catch serialization errors and more importantly the details of those errors, also.
More Info:
How do I create a global exception handler for a WCF Services?
Yes, IErrorHandler will also catch serialization exceptions. You will get all information stored in the exception. Whether or not this enough detail for you, I can't say.
Note that there may be client-side errors (serialization and others) which will never make it to the server. You will not see those with the IErrorHandler.