当出现问题时,我们看到我们的一些代码出现了一个奇怪的问题 - 在某些情况下,异常消息和堆栈跟踪不匹配。
我们有许多具有类似结构的消息处理程序,如下所示:
public void Handle(AddTelephoneNumber message)
{
var directory = ClientService.Directory(Context).Result;
var client = ClientService.ClientLookup(message.ClientNumber, Context).Result;
if (!client.Item1)
{
//Client does not exist
throw new Exception("Unable to locate client"); //A
}
//B Start
var clientPersonsLnk = client.Item2.Links.Single(l => l.Rel == "client-persons");
var persons = ClientService.Get<Persons>(clientPersonsLnk.Uri, Context).Result;
var person = ClientService.Get<Person>(persons.PartyUri(message.Party), Context).Result;
var phones = ClientService.Get<TelephoneNumbers>(person.Links.Single(l => l.Rel == "person-telephones").Uri, Context).Result;
var addPhoneLink = phones.Links.Single(l => l.Rel == "telephone-add");
var newPhone = new TelephoneNumber();
//Set up the new telephone number, elided from sample
//B End
var result = ClientService.Post(addPhoneLink.Uri, newPhone, Context).Result;
if (result.Item1 == HttpStatusCode.OK || result.Item1 == HttpStatusCode.Created)
return;
else
_logger.WarnFormat("ClientService.Post to {0} returned unexpected response code of: {1}", addPhoneLink.Uri, result.Item1);
//C
throw new Exception("Unable to process telephone number addition message");
}
我们观察到的行为如下 - 如果发生 A 或 C 之一,我们不可避免地会最终将消息传递到错误队列,并在消息扩展中提供以下信息:
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Message</Key>
<Value>Unable to process change person name message</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Source</Key>
<Value>ProjectName</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.StackTrace</Key>
<Value>System.Exception: Unable to process change person name message
at ProjectName.Handlers.ChangePersonNameHandler.Handle(ChangePersonName message) in c:TeamCitybuildAgentwork6601b33332f54f3cProjectNameHandlersChangePersonNameHandler.cs:line 45
at NServiceBus.Unicast.HandlerInvocationCache.Invoke(Object handler, Object message, Dictionary`2 dictionary) in c:TeamCitybuildAgentworkd4de8921a0aabf04srcNServiceBus.CoreUnicastHandlerInvocationCache.cs:line 63
at NServiceBus.Unicast.UnicastBus.<>c__DisplayClass2f.<DispatchMessageToHandlersBasedOnType>b__2a(Action dispatch) in c:TeamCitybuildAgentworkd4de8921a0aabf04srcNServiceBus.CoreUnicastUnicastBus.cs:line 1093</Value>
</HeaderInfo>
(很抱歉切换到不同的消息类型 - 我只是想找一个例子)
但是,似乎包括,如果异常消息与 A 点给出的消息匹配,那么堆栈跟踪,特别是这一行:
at ProjectName.Handlers.ChangePersonNameHandler.Handle(ChangePersonName message) in c:TeamCitybuildAgentwork6601b33332f54f3cProjectNameHandlersChangePersonNameHandler.cs:line 45
将始终包含 C 点异常的行号。反之亦然,如果我们收到应该在 C 行生成的异常消息,那么堆栈跟踪的行号将指向行 A。
B 部分中的方法引发的任何异常似乎都忠实地报告了正确的行号。因此,似乎直接在处理程序中抛出的异常具有这种奇怪的行为,但是我们调用的代码(例如,如果序列不包含任何元素,则从 Linq 中)引发的任何异常都像往常一样运行。
除了难以置信的胡言乱语之外,有谁知道有什么事情会导致这种转变发生?
从 packages.config:
<package id="NServiceBus" version="4.0.1" targetFramework="net45" />
<package id="NServiceBus.CastleWindsor" version="4.0.1" targetFramework="net45" />
<package id="NServiceBus.Host" version="4.0.1" targetFramework="net45" />
<package id="NServiceBus.Interfaces" version="4.0.1" targetFramework="net45" />
<package id="NServiceBus.NHibernate" version="4.0.1" targetFramework="net45" />
或者我应该做任何进一步的调查,更多信息添加到问题中等?
1)
private void SomeMethod ( )
{
try { //some code here }
catch ( Exception е)
{
throw е : / / CLR thinks that the exception line is there.
}
}
2)也可能是由C#编译器优化引起的,尝试将属性添加到您的方法中以检查出来:
[Methodlmpl(MethodImplOptions.Noinlining)]
3) 您是否正在使用隐藏实现详细信息异常模式?
在我自己看来,这是因为编译器优化,因为它可以切换行并稍微优化代码。
我在一起使用 Lambda 表达式和 Linq 时遇到了许多奇怪的行为。在运行时和编辑器中(包括频繁的 IDE 崩溃 [与计算机无关])。因此,我会重写没有 Linq 和 Lambda 表达式的 B 部分。