问题
Here's my problem. I have a middleware web service used by several web clients. The web service is a wrapper service that makes calls to several vendors' web services. The call to the vendor's web service is wrapped in a TryCatch but any exceptions generated aren't getting caught by my web service, they're getting caught in the client apps.
Am I missing something? Is this related to this posting?
Here's a simplified code snippet:
Dim VendorWebservice as New VendorWebservice
Dim VendorResponse As VendorResponse = Nothing
Dim ClientResponse as New CustomClientResponse
Try
VendorResponse = VendorWebservice.VendorWebMethod
Catch ex As Exception
ClientResponse.ErrorMessage = ex.Message
ClientResponse.Status = "VendorError"
Return ClientResponse
End Try
EDIT
To expand upon some of the details... The code runs successfully 99+% of the time. On the rare occaision that there is some issue with the vendor's web site is when this issue is occurring. I've had VS opened for both one of the web clients and the web service and can step through the code from the client to the WS and back. When I can reproduce the issue, I have stepped through the client code to where it calls our web service, then switch to the WS code and step through until it calls the vendor's code and at that point, it jumps back to the client code, without hitting the Catch block or any code after it.
Hope that helps.
EDIT
Some of the posted answers have provided avenues to research, most notibly that there are exceptions that can be created that are not derived from System.Exception. (Who knew?) But I also found out that from .NET 2.0 and later, these non-System.Exceptions are getting wrapped by .NET in a System.Exception. So in theory that should rule non-System.Exceptions out.
Additionally, from my reading, when calling a web service (like my web service is doing) theoretically only two types of exceptions should ever really be seen, System.Net.WebException and System.Web.Services.Protocols.SoapException, both of which derive from System.Exception. I don't know if it is really true if there are only 2 types of exceptions possible when calling a web service, but I'll throw it out there. :)
Still searching for an answer...
EDIT
Reproducing the error condition has proved to be elusive. Every scenario that I've thrown at the code has responded as expected, with the error being caught in the Catch block. While in theory .NET is supposed to be wrapping exceptions that do not derive from System.Exception, the only logical answer appears to agree with Joe's answer that the exception we have experienced does NOT derive from System.Exception and thus is treated as an unhandled exception.
回答1:
Are the exceptions being thrown derived from Exception? (Does 'Exception' definitely refer to 'System.Exception')
回答2:
are you sure the exception happen inside the try/catch?
try moving the "as new" inside the try/catch too
回答3:
I've seen this same error before in some code from a previous job. In our case the error that was being thrown did NOT derive from System.Exception. Once we knew that, it was pretty easy to handle it properly.
回答4:
I know this is a very old question, but I just ran into this situation, and nothing I found online helped. After banging away at it, I finally stumbled upon an answer, though I cannot explain the why. Here it is in a nutshell:
This is a scaled-down version my original code that wasn't working:
Try
File.Copy(FromFile,ToFile,True)
Catch ex As ApplicationException
[Error handled here]
End Try
The file copy was likely to result in a file-in-use error, so it was important that I could trap it, but the above would just throw an error, as described in the above discussion.
I was able to fix the problem by changing the code to:
Try
File.Copy(FromFile,ToFile,True)
Catch
[Error handled here]
End Try
Removing "...ex As ApplicationException" solved the problem, and now errors in the file copy operation are trapped. I don't like that I can't examine the actual error, but in this case I can pretty safely assume what the error is.
Again, sorry that I don't know why this works; I may try figuring that out at some point, but at least I can move on from this problem.
回答5:
It is common for web services not to throw exceptions, but instead to return some kind of error object or error message or status. If you put a breakpoint after you call VendorResponse, you can examine what was returned and see if there are any "error" or "status" properties. If so, you can test for the contents of those in your code and then throw an exception or otherwise handle the situation.
回答6:
I personally find it hard to believe that an error is occurring in this code and not being caught in the try catch. Maybe put a finally and see if that executes.
First, you need a decent way to recreate your error.
The next thing I'd do is attempt to figure out exactly where in the code the error is being thrown. What I'd do would be to temporarily put in logging (Debug.Output maybe) statements after each line of code so that you can be sure which lines actually executed.
When your error occurs you'll be able to look at the output of these logs to see at least where the error is occurring. Now that you know this, it may give you a better idea of what's going on. If all of the logging statements appear, then you'll know the error isn't occurring in this block of code. My initial guess is that's what's happening.
Since nothing is falling into the catch, then you need to eliminate everything else that might be going on. If possible, put this bit of code into a tiny test harness app to see if it functions properly.
Hopefully some of that will help.
来源：https://stackoverflow.com/questions/2006149/try-catch-not-catching