不具有堆栈跟踪例外 - 怎么样？ [英] exception with no stack trace - how?

问题描述

我们都将在（通过log4net的）应用程序域级别记录未处理的异常的服务

我们记录：

2014年1月28日16：49：19636错误[49] FeedWrapperService - 未处理
System.NullReferenceException：对象未设置为一个对象的实例引用

这异常没有堆栈跟踪。 ？这怎么可能没有做一些疯狂的事情来异常对象

我们的处理代码：

  AppDomain.CurrentDomain.UnhandledException + = LogAnyExceptions; 
 
私人无效LogAnyExceptions（对象发件人，UnhandledExceptionEventArgs E）
 {
 log.Error（未处理（例外）e.ExceptionObject）; 
掷（异常）e.ExceptionObject; 
} 
  

它发生，我认为再扔在这里是没有意义的，因为在AppDomain会与过程一起回落无论如何，但我不认为这会影响我们的情况。

Windows应用程序事件查看器还显示只有这个空裁判例外，没有痕迹。

我测试过的异常处理程序日志记录，并成功登录的堆栈跟踪以及任何内部异常。如果它是由我们的代码抛出，我们将看到一个堆栈跟踪。如果它是由第三方C＃库抛出，话又说回来，我们将看到一个堆栈跟踪至少一种方法的（无论是重新抛出的异常与否）。在这里我们看到不具有堆栈跟踪托管异常。我不知道这是怎么可能的。

综观反编译的第三方库它谈论非托管代码，并引发该异常的事件很可能在未管理土地，但是怎么会这样的情况导致没有一个堆栈跟踪被管理空裁判例外呢？

这个问题的原因是间歇性的。我们一直运行在生产这个代码几个月，看到它这样做一次。这是很奇特的。

普遍的共识是，负责这种问题应该是系统推离成一个子进程，所以我们可以处理这个问题，并重新启动安全

$ b：自动，但它会很高兴地知道发生了什么事情。

修改，包括评论从下面的信息
$ b

我的例外是不是一个标准再扔，因为堆栈跟踪null或空。它不具有在它的再投掷方法的名称。进一步挖掘，异常类可以从序列化的信息来构建，它看起来像序列化的信息可能包含堆栈跟踪空字符串，以及潜在可能，而不会导致其他错误创建。我想这可能来自那里，但我不知道它是如何起源。

解决方案

如果您收到一个异常但没有相应的堆栈跟踪，然后在某个时刻异常处理程序可能是评估异常，并重新把它扔不正确。例如，如果你在做一个罚球前; 你会吃的堆栈跟踪，导致了这一点。要保留您要在现有调用堆栈简单地扔;
的抛出异常

请注意，在C＃的方式是公约Java语言，在这里你都应该<相反的最佳实践code>罚球前; Java参考：最佳实践：捕获并重新抛出Java异常

We have a service which will log unhandled exceptions at the app domain level (via Log4net).

We logged:

2014-01-28 16:49:19,636 ERROR [49] FeedWrapperService - unhandled System.NullReferenceException: Object reference not set to an instance of an object.

This exception has no stack trace. How is that possible without doing some crazy things to the exception object?

Our handling code:

AppDomain.CurrentDomain.UnhandledException += LogAnyExceptions;

private void LogAnyExceptions(object sender, UnhandledExceptionEventArgs e)
{
    log.Error("unhandled", (Exception)e.ExceptionObject);
    throw (Exception)e.ExceptionObject;
}

It occurs to me that the re-throw here is pointless because the AppDomain will come down along with the process anyway, but I don't think it affects our situation.

The windows application event viewer also shows only this null ref exception and no trace.

I've tested the exception handler logging and it successfully logs the stack trace and any inner exception. If it was thrown by our code, we would see a stack trace. If it was thrown by the 3rd party c# library then, again, we would see a stack trace of at least one method (whether it was a re-thrown exception or not). Here we see a managed exception with no stack trace. I don't know how this is possible.

Looking at the decompiled 3rd party library it talks to unmanaged code, and the event that raised this exception is likely in unmanaged land, but how could such a situation cause a managed null ref exception without a stacktrace?

The cause of this problem is intermittent. We've been running this code in production for several months and seen it do this once. It's pretty freaky.

The general consensus is that the system responsible for this kind of problem should be pushed off into a child process so we can deal with the problem and restart safely and automatically, but it would be nice to know what's going on.

Edit to include comment info from below:

My exception is not a standard re-throw, because the stack trace is either null or empty. It does not have the name of the re-throwing method in it. Digging further, the Exception class can be constructed from serialized info, and it looks like the serialized info could contain null strings for stack trace, and potentially that could be created without causing other errors. I guess it might come from there, but I don't know how it originated.

解决方案

If you're receiving an exception but no corresponding stack trace then at some point an exception handler is probably evaluating the exception and re-throwing it incorrectly. For example, if you're doing a throw ex; you'll eat the stack trace that led to that point. To preserve the existing call stack you want to simply throw; Throwing exceptions best practices

Note that the C# way is the opposite of the convention for the Java language, where you are supposed to throw ex; Java reference: Best Practice: Catching and re-throwing Java Exceptions

这篇关于不具有堆栈跟踪例外 - 怎么样？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！