Managing a correct error handling process in an application is a nightmare if you want to do it properly and I would say that it is not always the best exciting part, but it is absolutly needed to prevent as much as possible unhandle situation. In a normal application you simply place the code inside try-catch block with the exception type, and there are handle as normal .net exception object that you can bubble up.
With WCF service I have discover around different reading that it is a bit different, simply because WCF need to guaranty interoperability with any client application in order that they are able to catch error returned.
For that WCF need to convert the “normal .NEt exception” into a SOAP message exception that will be understandable from client application.
To achive this you need to specify a FaultContract attrribute in your service either declaratively or imperatively way. For my case I have done it with declarative.
You specify the declarative FaultContrat as follow for your service method:
[OperationContract] [FaultContract (typeof(MyError))] Boolean myMethod();
MyError is here a custom type which define an error message
After having configured the service FaultContractAttribute, next you need to raise the exception from your server side service method code as follow :
Server side
catch (Exception exc) { MyError ErrLog = new Maillefer.Nomos.Types.Common.MyError (“This is an error”,”Critical”); FaultException<MyError> fe = new FaultException<MyError >(ErrLog, new FaultReason(ErrLog.Message)); throw fe; }
So far so good. Then from the client application side you simply need to catch the FaultException error type as you normally do and retrive the message return by the Servcie SOAP message as follow:
Client side
catch (FaultException MyError) { string msg = Error.Detail.Message; MessageBox.Show (msg); wcfclient.Close(); }
And that’s it. You then receive the error message send from your server, inside your client application.. Hmmm this is what I was expecting but it was not behaving as expected. I spend days to cross check my code and verify impementation to get the exception correctly thrown but when runnig my application my service was stoping at the time it was throwing the exception (throw fe). The error return from that execution was something strange like :
“System.ServiceModel.FaultException`1 was unhandled by user code“
After a lot of research I find out the solution on a post mentionning that it was due to some setting of debugging scenario of my VS environement, which make my code execution stop at each exception with not really logic message wich was giving a lot of confusion.
To remove this behaviour it was advise to uncheck the 2 following options from the Tools->Option menu of IDE:
Hoping this post will save you a lot of research time. Once again, every thing works until you hit the point that gives you nightmare 🙂
You’ve Got to be Kidding Me… That’s it?!?
I, too, have spent days trying to figure out what was wrong with my code. I would reach the point in my service where I said Throw New FaultException… and it would then move to the next line of code and try to process it. I tried to find a way to actually get it to THROW and stop execution, but nothing worked, because I got the infamaous FaultException’1 message. But once I changed the options you mentioned in this post and reran the code, it worked just like it should and the error was captured in the client.
Thank you so much for posting this!!
No problem Sam, I fight so long time to find it I though it would be more than helpful 🙂
Hello,
Thanks for you post.
I did made the change in settings under Tools->Options, but now instead of throwing error it just passes the error generating steps silently.
Any clue?
Are you cathcing this fault exception at the client side ?
This tips was locking teh exception to be escaladate to client side.
Hi ,
Thanks for you post.this Helped me
Sensational, I have been going over code for hours trying to figure out what I was doing wrong, had the same issue in a vb.net wcf solution…
Thank you so much…very very useful.
Cheers Mate
Same here.
Got this error using the enterprise library validation block and WCF …after hours of head banging ..this post saved the day
Thanks a Lot Dear,It works wonder
You can also go to Debug -> Exceptions -> Common Language Runtime Exceptions, and uncheck “User-unhandled” for System.ServiceModel.FaultException`1. That way, only that specific type of unhandled exception will not cause a break.
very strange that those options would have any impact on this… neither control what exceptions are handled…
I have encountered this problem and noted that a try/catch around the ‘end’ method catches the fault whereas the try/catch around the calling and/or async method does not….
Thanx Buddy….It worked.
But again I stucked to other error..
ie- Cannot directly jumped to Server.Debugger is already attached.
You can help me out….????
what do you mean by that, could you explain more
Thank you soooooooo much! I’ve been searching for DAYS for this problem! I thought it was something in my code, and I couldn’t believe RIA services did not enable exception handling on the client side
You made my day!! What do I say? You made my week!!! 🙂 🙂
Thanks a lot!
mais de rien Olivier ce fut un plaisir
Thank you!! This worked perfect… =) =)
Thank you very much. It was a lot of help
I dont find much difference intially it was throwing the error as exception, after these changes it showing the same one in stackTrace as “The creator of this fault do not specify a reason” in Reference.cs. Help me for the same.
Try to add in your FaultException definition the New Faultreason as a parameter and specify corrcet attributes.
Thanks for posting this. I have no idea what it actually does, but turning the two debugging options off, did the trick for me.
Great job.
Thanx alot. it solved my problem..
Hi Thank you so verry mutch. Your information saved me many hours debuging.
Keep ut the good work 🙂
/Adam
Thanks a lot, Your information saved me many hours debuging. And i’m not sure, i found the solution.
Thanks man! I am sure I would have spent days on that one too had you not posted this.
Serge – Where do I send the cheque ? I have spent 4 days trying to determine why I could not sucessfully throw an exception from a WCF service.
Thank you.
i can only say thanks so much =D you save me from a lot of time waste
Thanks dost, i got your post after a long Google search :). thanks again for this help 🙂
I am facing the same problem as my WCF is throwing “” when i throw an exception, after doing the desired changes in Tools–>Options–>Debuggging…, Its now executing the code as desired (NOT :-()
Well, i am using a Silverlight 4 application client and it calls the wcf operations and Async calls. Now after the Fault is thrown from WCF, my code does not execute Catch block at all.
Anyways, i did this;
if (e.Error != null)
MessageBox.Show(e.Error.Message);
else
MessageBox.Show(“Sucess”);
but to my surprise, the fault is not what i threw. in fact its not even going to catch. Its saying “The remote server returned error : NotFound”.
Please suggest….
could you psot a sample code which reproduce your problem ?
Silverlight 4 is highly prone to Cross-Domain Policy issues. I recently had troubles with my service NOT being found from Silverlight. I’d go to http://localhost:9091 and see that the service was running. Then I was able to successfully run the WCF test client, but everytime Silverlight complained about not finding my service.
In fact it’s just being blocked. I had people tell me “you shouldn’t need a cross-domain policy since your service and client are on the same network”… BS! My service and client, in fact, were on the same localhost, but with different port numbers, and it would NOT work without a cross-domain policy or a client-access-policy file.
What’s worse is that I had to find a way to provide a cross-domain policy in a self-hosted WCF service; I wasn’t using IIS. In the end, I found a solution that essentially creates another service end point in my WCF self-hosted service which provides a clientaccesspolicy.xml file when you type in http://localhost:9091/clientaccesspolicy.xml. Once I can type that in a browser and get the XML file, then my Silverlight client was finally able to use my WCF service.
Have you try to implement your service call with RIA to see if you get same issue?
Thanks a lot! This really helped me, because I’ve spend much time and nerves getting this to work. In VC#2010 Express you need to untick just one option:
Enable Just My Code
Thanks for posting this. It did save my time..
you welcome
Thanks. Really helped!
Thanks — this saved me a lot of time!
Unbelievable, Thanks a lot! I have one more question, Will everything works well when I deploy to a production environment? Is there any extra configuration?
It is just within VS environement. I will work normally under deployement
Thank you Serge !
Likewise – I’ve just killed a couple of hours trying to figure this out. Great to finally see the answer!
I really feel like kicking Microsoft in the balls right now. Does anybody now what those options actually do?
Maybye you now how to fix it on wp7?
unfortunatly never do wcf on wp7 so far
Hello , Thanks for this post.It solved my problem in seconds. I have spend so many hours solving this issue.
Great Help….
OMG!! Thanks a lot!!
Thanks this kind of errors take a lot of time, and when you are looking for solutions you feel the only person with the problem and a like a fool, you see a lot of people explaining it in the same way as you do, and you percibe some like !! Where is the diference !! and so one day after other… Really thanks
OMG….. Thanks a lot.!!!!!
Thanks a lot. You saved my day/week/…
thanks it worked for me too and saved lot of time.
Really you are great!!!!!!!! Thanks a lot….
Thanks it worked.
What I find surprising is that Visual Studio designers provide the “A first chance exception of type ‘System.ServiceModel.FaultException`1’ occurred in WCF Service.dll” message, without a corresponding suggestion to disable this under Tools/Options, or even an indication to suggest that this is not programmer error but a feature of the debugger which by default is turned on, as budding developers new to the environment are so obviously bamboozled.
Clearly, the Visual Studio designers have overlooked the potential to reflect on the service to discover if FaultContract attributes exist and if so suppress the warnings.
I’m afraid it’s a sad reflection on the industry when, the desire to keep ahead of the competition and set the technological pace of change, that basic instruction (e.g. MSDN Help) is provided only for those, and only understandable by those with the benefit of years of experience.
Thanks to you Serge for sharing the solution to your problem after spending so many fruitless and wasted hours on something that should be clearly documented – the world is a better place for folks like you.
For anyone else panicking because the image is down, go here: http://social.technet.microsoft.com/wiki/contents/articles/17418.the-famous-system-servicemodel-faultexception1-was-unhandled-by-user-code.aspx
Thanks for the info. The image is back on the post, no idea how it has been removed 🙂