This is the exception I get:
An exception of type 'System.ServiceModel.FaultException`1' occurred in TestService.exe but was not handled in user code
I try to run my client and the debugger gets caught when I try to do the following
catch (Exception ex)
throw new FaultException<GeneralCalculatorFault>(fault, ex.ToString());
What could be the problem. Let me know if I need to provide more info.
I answered the question myself. It was giving me trouble because of a setting in Visual Studio 2012.
Whenever the exception was thrown if I pressed "Continue", it handled everything just fine on the client side just like it should. There is a checkbox on the server side that allows me to ignore exceptions of particular types, so I checked it and now the server side no longer complains that the exception is not being handled.
Maybe this will help some other newbie like me. :)
Related
I am just learning WCF and wrote a Windows Service hosting a WCF service. Ever since I started it in service.msc in the remote server (physically remote, and very slow) I think I have already hit and fixed like a hundred errors here and there already. I am now finally stuck.
At this point, I have enabled tracing and message logging. The first and only function call looks like this:
[OperationContract]
public MyServiceResponse ConnectToAXDynamicsViaDotNET2BusinessConnectorWithSadFace()
{
try
{
throw new NotImplemented();
}
catch(Exception ex)
{
return new MyServiceResponse(ex, ex.Message);
}
}
[DataContract]
public class MyServiceResponse
{
// ...
}
Upon calling the operation, the client just sits and waits until timeout. Checking the trace, it records my thrown exception. So it makes me wonder if WCF actually blocks there and ignore my catch clause.
I then tested with just a simple return value without throwing and it FINALLY works.
My question is, how then can I make the above scenario work, ie. catch the exception and return a sensible result back to client? Maybe it's just the tracing that blocks me, but I want to enable tracing during this whole debugging process otherwise it's really hard to work.
Thanks for your precious help!
EDIT: Sorry, I found this right after I posted this question. Happens all the time: http://msdn.microsoft.com/en-us/library/ee942778.aspx but I have yet to read it as I got to run off now. Not sure it it will solve my problem.
Risk being downvoted, but just for documentation sake and general usefulness of having this question:
Through reading the FaultException handling articles, I guess the above behavior is due to Exception class not serializable. And the service silently disconnects itself without returning any error messages eventhough the "send (unknown) faults to client" is enabled. As for why it does so, I have no idea yet. Will update if I find out more.
I have since changed to throw new FaultException() instead of returning my own MyServiceResponses.
I recently migrated a VB6 app to VB.Net. Entire VB6 dependency are removed . And the code was working fine just for a single module mean to say like for WinApp it is working fine.
Now my requirement has been changed, now the same class will be accessed by multiple application , it might a Windows App, Web App or a web service. So I am not able decide any efficient error handling pattern.
So you you guys help me out. Currently what I am doing is that parent function , i am passing two vars LogError as bool and ErrorMessage as string parameter, that will further check something like this
Catch(ex as Exception)
If LogError then
MessageBox.Show("My_Module_Name :" & ex.Message)
EndIf
ErrorMessage = ex.Message
End Try
Also same catch block is used in all other functions/ subroutines.
So what I need is any elegant handling method that will work efficiently on cross-app platform(win/web/service)
I'd suggest logging the messages, either to a log file or to the Event log, but why not let the clients choose, in that you could add some methods to let the client decide where it should be logged. Though instead of having your exception handler handle the message and put it into an errormessage variable I'd just follow the logging with a throw so that the Exception continued up in the call chain until some code that knew how to handle it got it.
In general it's not good practice to catch Exception, you should catch only the exceptions that you can handle. But I think it's ok if you just want to log it and then will re-throw it again.
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?
This might be a good place to start: Expected Exceptions.
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.
Just thinking outloud... one solution could be:
Add the list of exceptions(and exception casting) in your Custom exception class; for instance CException.
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.
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!
When I do the try/catch method in my vb.net project I will try the code I want and when it can't do it, i make a message box right after the catch method. The thing is that it will show the message box, and then another message from the program itself. Like for example, I have here a MySQLException, and when i click ok on the message box, it will show another one right after showing the exception itself. How would I be able to get rid of this so the user doesn't have to see this, and the program can continue.
Thanks,
kevin
It sounds like you're actually getting more than one exception. Have you checked the stack traces for both errors?
What I think is happening is that your first function is throwing the MySQLException and then returning nothing. You're then probably getting a NullReferenceException from whatever made the call to the database.
Your best bet is to not catch some many exceptions. Your data layer should be free of Try/Catch blocks unless you're trying to cater for something very specific. Your business layer should then catch any other non-general exceptions that occur specific to the functionality there. Finally, your application layer should be handling all of your general exceptions and reporting on them from there.
Try this. It should only display one message. Make sure your original message is coming from a statement after the Try.
Try
code
Catch ex as exception
call msgbox (ex.message)
end try
've been running through the MSDN help documents to get a hang of Visual Basic. After trying out the example using timers --one drags a label and timer component into the designer and adds the following to the components subroutine
Label1.Text = My.Computer.Clock.LocalTime.ToLongTimeString
The output for the immediate window during debug is the following
A first chance exception of type
'System.InvalidCastException' occured
in Microsoft.VisualBasic.dll
A first
chance exception of type
'System.InvalidCastException' occured
in Microsoft.VisualBasic.dll
The same error occurs on a previous MSDN example using a context menu component. Should I Try...Catch...Finally this error and try to move on? Or, am I dealing with something much more serious?
When you see something about a first chance exception, it only means that an exception was caught within the code you called but does not necessarily mean that the code failed. If the code runs without causing your program to crash and returns a valid value, then do not have a problem. You will also see output in the debug window about first chance exceptions when you implement your own try/catch blocks.
In the Debug menu -> Exceptions, you can enable the debugger to stop when an Exception is first thrown, even if it would be caught later; if you want to find out what's happening, this is the easiest way to do it
In the first chance exception examine the details of the exception. You should see a stack frame/trace property. In there you should see what line the error occurs on. This should help you.
In the IDE try going to Tools > Options > Projects and Solutions > VB Defaults and setting Option Strict to 'On' - this may help catch casting problems when you compile your project rather than when you run it.
A 'first chance execption' does not necessarily mean you have a problem in your code. It could mean the IDE or the compiler or any other involved component encountered and handled an error and in the process the debugger is notified and the exception is being reported to the immediate window. This is an excellent post on the topic:
http://blogs.msdn.com/davidklinems/archive/2005/07/12/438061.aspx
A quick and easy solution for debug and diag of First Chance Exception is :
AppDomain.CurrentDomain.FirstChanceException += CurrentDomainOnFirstChanceException;
and then
private void CurrentDomainOnFirstChanceException(object sender, FirstChanceExceptionEventArgs firstChanceExceptionEventArgs)
{
if (firstChanceExceptionEventArgs.Exception is NullReferenceException)
{
// do your handling and debugging :)
}
}
Multiple First Chance Exception during the runtime can cripple the performance of your application because exception handling is expensive. Especially in web apps. You can add this handler and look at specific first chance exceptions and try to avoid/correct them.