4

Running a WCF service inside Visual Studio, I see a load of exceptions in the Debug output.

A first chance exception of type 'System.ServiceModel.FaultException' occurred in System.ServiceModel.dll
A first chance exception of type 'System.InvalidOperationException' occurred in System.ServiceModel.Channels.dll

They seem to get thrown irregularly: in any case I haven't been able to work out any pattern (i.e. anywhere from every few seconds, to several tens of seconds).

If I set debug to break on FaultException, I see that they are being thrown by System.ServiceModel.Dispatcher.ErrorBehavior.ThrowAndCatch(Exception e, Message message).

The exception message is {"The message with To '' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree."}.

The obvious answer would seem to be "well your address is empty". But this happens before any clients have connected.

Is this just 'normal', or a symptom of something I'm doing wrong?

Benjol
  • 63,995
  • 54
  • 186
  • 268
  • Just to clarify, your project is a WCF service, right? How are you connecting to it and invoking the methods? Another project in the same solution? WCFTestClient.exe? – Boluc Papuccuoglu Jan 16 '14 at 11:15
  • @BolucPapuccuoglu, that's the thing, right now I'm NOT connecting to it... – Benjol Jan 16 '14 at 14:56
  • I've been using WCF for years, but I don't see those particular first-chance exceptions that you have mentioned. However, I do routinely see a variety of others, since WCF internally is handling them, they are just extra noise in the debugger and don't provide any useful diagnostics for me. – Chris O Jan 16 '14 at 15:02

3 Answers3

4

The quick answer is "yes, you could ignore first chance exceptions". They are exceptions which have actually already been handled. Therefore, they should be considered as a normal execution workflow.

The visual studio notifies the developer for each exception it occurs, even if it is handled. Each exception throws a "first chance exception" which does not interrupt a normal debugging session. If this first chance exception is not handled, then the debugging session gets interrupted by a "second chance exception". The value of the "first chance exceptions" is only for developer's insight knowledge.

In this blog post you can see more details about first chance exceptions. Copying from the referenced post:

Does a first chance exception mean there is a problem in my code? First chance exception messages most often do not mean there is a problem in the code. For applications / components which handle exceptions gracefully, first chance exception messages let the developer know that an exceptional situation was encountered and was handled.

Hope I helped!

Pantelis Natsiavas
  • 5,293
  • 5
  • 21
  • 36
  • 1
    Surely the type (i.e. the cause) of the exception matters? The OP's case doesn't look like something that should 'just happen'. Isn't the framework just swallowing exceptions here; something that it's commonly said user code should never do? – Tom W Jan 16 '14 at 12:44
  • 1
    .NET framework is code written from programmers like us. They handle exceptions as we do. Visual studio will inform the developer for a first chance exception, regardless of the code part they are handled in. Therefore, while you are right about not using exceptions excessively, this does not mean that it is wrong to handle them gracefully. – Pantelis Natsiavas Jan 16 '14 at 12:49
  • 1
    What I am getting at is that in the case described by the OP at least, I'd be worried if I saw that the framework was routinely throwing and handling that kind of exception. It doesn't seem to me to be something appropriate to see in normal use. I realise I'm diverging from the original question and speculating on the design of the WCF assemblies, so that's probably a conversation to be had elsewhere. – Tom W Jan 16 '14 at 12:55
  • @TomW: you would be mistaken to be concerned about first-chance exceptions. The .NET developers are some of the best in the world - their code doesn't just swallow exceptions. – John Saunders Jan 16 '14 at 14:41
  • @JohnSaunders By any chance are you being facetious? The WCF source code is quite large and complex, of course they must handle some exceptions internally, those that they deem safe to do so, without hosing the entire app. – Chris O Jan 16 '14 at 15:11
  • @ChrisO: therefore, first-chance exceptions from Framework assemblies should be ignored. Also, user-written code that swallows exceptions should be fixed, and their developers severely punished. At that time, first-chance exceptions should be ignored entirely. – John Saunders Jan 16 '14 at 15:15
  • @JohnSaunders, so where's your answer so I can upvote it? :) My experience (limited as it is, otherwise I wouldn't have asked the question), is that first chance exceptions in code I'm relying on can *sometimes* mean I'm using it the wrong way. I at least like to understand why. I guess in this case I'll just have to go look in Reflector :( – Benjol Jan 17 '14 at 05:57
  • @Benjol If you have doubts on how you use .NET libraries, I would suggest looking at the MSDN. Using Reflector is an overkill! Sometimes exceptions are not an option, are a necessity and there is nothing wrong about it. Diving that deep is not necessary... – Pantelis Natsiavas Jan 17 '14 at 06:01
  • @Benjol If WCF internally is handling exceptions, then you don't have to care about those, it's not part of their public API, and you and I are only clients of the WCF library. If WCF is raising exceptions, then that **IS** part of their public API, and us folks who use the WCF library now have to care, a lot, about these exceptions, and must decide what to do for those "exceptional" cases (assuming that the WCF devs do in fact raise *quality* exceptions for the right reasons, and do not abuse the exception system in windows merely to pass info back up the callstack because they can). – Chris O Jan 17 '14 at 14:55
0

Normally, if you see first chance exceptions in the debug window, but if they do not crash, say, the w3wp.exe process when running without a debugger attached, you can be pretty sure that the framework or the generated classes are catching the exceptions and dealing with them. However, if there are an inordinate amount of such messages or that you suspect that none should be thrown, even if handled, you can use Visual Studio's exception settings to break on handled errors so you can debug/trace.

Boluc Papuccuoglu
  • 2,318
  • 1
  • 14
  • 24
0

I agree that all of the first chance exceptions thrown from the framework can be safely ignored, we have found it useful to catch hidden / very hard to replicate bugs on production codebase if an excception gets swallowed (and not 'handled'). Attaching a handler for FirstChance exceptions which logs to a separate log file and is enabled only in a QA environment (these logs are huge) helped us find several bugs in our own codebase. A developer looks at the log file at the end of the day for anything which should not be safely ignored.

While these kind of bugs should have never been in the code in the first place had someone not decided to just swallow an exception, in a messy real world, this is a great tool to continualy improve quality of the codebase.

Rahul Misra
  • 561
  • 1
  • 7
  • 15
  • The best practice would be to not swallow exceptions. – John Saunders Jan 16 '14 at 14:39
  • I can't agree more with you John as I've mentioned. However, we often find ourselves supporting a large codebase which has swallowed exceptions. It could be the ignorance of a developer or maybe the exception gets swallowed somewhere higher up the call stack. – Rahul Misra Jan 16 '14 at 14:44
  • Having any full regression test cycles coming up? ReSharper has a feature that should enable you to place logging in all the places where exceptions are swallowed. Of course, you then need to test them. – John Saunders Jan 16 '14 at 15:02
  • I believe Periodically looking at FirstChance exceptions is a useful tool if when a developer available to analyse the logs for a couple of hours. This is especially relevant to legacy code which is assumed to be running fine on Prod. With thousands of classes around on a huge application, it is not possible for QA on a tight budget to execute every possible test scenario. This is not a replacement for the best practices and QA testing but an additional tool to proactively improve codebase. – Rahul Misra Jan 16 '14 at 16:04
  • Ok, but that's not what I was implying. I was implying that "structured search and replace" can be made even to large code bases if a safe manner. You would, of course, want to test whatever code was changed. – John Saunders Jan 16 '14 at 16:06