错误设置断点，但仅在调试时在某些行上 [英] Error settings breakpoints but only on some lines while debugging

问题描述

此行导致 PostEntityImages 集合中的找不到密钥。

 实体pimage = _context.PostEntityImages [ postcreate]; 
  

当我在该行上放置一个断点并将其放在监视窗口中时，它工作正常，并且

UPDATE：

 受保护的覆盖无效ExecutePlugin（）
 {
 
 try 
 {
 Entity pimage = null; 
 if（_context.PostEntityImages.ContainsKey（ postcreate））
 pimage = _context.PostEntityImages [ postcreate]; 
} 
 catch（Exception）
 {
 //永远不会碰到这条线
抛出； 
} 
} //进入/遍历分配pimage的行时，执行将跳至这一点，然后被此方法调用程序的catch块捕获。 
  

更新＃2：

在调试模式下，可以设置一些断点。其他人给出错误消息无法设置以下断点：

解决方案

您描述的断点和单步行为是通常是由于尝试在发布构建配置中调试项目引起的。在这两种情况下，您最有可能遇到编译器因它们无关紧要而使代码行最优化的情况。

例如，如果您具有以下代码：

  try 
 {
 throw new ArgumentNullException（ foo）; 
} 
 catch 
 {
 var x = 0; 
投掷； 
} 
  

catch 块以上是没有用的，并且编译器的流分析足够聪明，可以确定可以安全地对其进行优化。如果您在运行这种经过优化的构建时单步执行代码，则只需跳过异常处理程序，然后跳转到调用者的异常处理程序即可。设置断点也会产生奇怪的错误，特别是如果您在调试程序时尝试将它们设置在优化的行上。

在调试中，非经过优化的构建，编译器将保留原本毫无意义的语句（例如，将值分配给不再使用的变量），特别是因为它们是有用的调试工具。

请确保您使用的任何构建配置都没有在项目的构建属性中设置优化代码复选框。请注意，配置的名称对VS没有意义-如果将项目的构建配置命名为 Debug，但打开优化，则将获得不可调试的构建。

This line is causing the "key not found" in the PostEntityImages collection.

Entity pimage = _context.PostEntityImages["postcreate"];

When I put a break point on that line and put it in the watch window it works fine and that key is present.

UPDATE:

protected override void ExecutePlugin()
{

try
{
    Entity pimage = null;
    if (_context.PostEntityImages.ContainsKey("postcreate"))
        pimage = _context.PostEntityImages["postcreate"];
}
catch (Exception)
{
    // Never hits this line
    throw;
}
} // When stepping in/over the line assigning pimage, execution will jump to this point, then be caught in the catch block of this methods caller.

UPDATE #2:

While in debug mode, some breakpoints set fine. Other give the error "The following breakpoint cannot be set:"

解决方案

The breakpoint and single-step behavior you're describing is usually caused by attempting to debug your project in a "Release" build configuration. In both cases, you are most likely running into cases where the compiler has optimized lines of code away because they are irrelevant.

For example, if you have the following code:

try
{
  throw new ArgumentNullException("foo");
}
catch
{
  var x = 0;
  throw;
}

The catch block above is useless, and the compiler's flow analysis is smart enough to determine that it can be safely optimized away. If you were to step through the code when running such an optimized build, it would just skip right over your exception handler and jump to the caller's exception handlers. It would also produce strange errors setting breakpoints, especially if you tried to set them on an optimized-away line while your program was already being debugged.

In a debug, non-optimized build, the compiler will keep statements that would otherwise be meaningless (such as, assigning values to a variable that is never used again) specifically because they are useful debugging tools.

Make sure that whatever build configuration you are using does not have the "Optimize Code" checkbox set in the project's "Build" properties. Note that the name of the configuration is meaningless to VS -- if you name your project's build configuration "Debug" but turn on optimization, you get a non-debuggable build.

这篇关于错误设置断点，但仅在调试时在某些行上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！