perl 调试 条件断点_使用条件断点进行更好的调试

perl 调试 条件断点

I love conditional breakpoints. Really! They're my favorite debugging tool.

我喜欢有条件的断点 。 真！ 它们是我最喜欢的调试工具。

When I got started in web development, "debugging" for me meant creating a <pre id='log'></pre> and appending strings to its contents to act as a log. But once Firebug rolled around—and then when browsers started baking in their own dev tools—it was like upgrading from a skateboard to a private jet. Breakpoints, watches, call stacks, profilers, network activity monitors—they're all useful, and I wouldn't want to lose any of them.

当我开始进行Web开发时，对我来说，“调试”意味着创建<pre id='log'></pre>并将字符串附加到其内容以充当日志。 但是，一旦Firebug出现 ，然后当浏览器开始使用自己的开发工具进行烘焙时，就像从滑板升级到私人飞机一样。 断点，监视，调用堆栈，事件探查器，网络活动监视器—它们都很有用，我也不想丢掉它们。

But conditional breakpoints are my favorite, and it's not even close. Here's how I use them:

但是有条件的断点是我的最爱，而且还差得远。 这是我的使用方式：

仅在某些情况下破裂 (Breaking Only in Certain Conditions)

The obvious case is the one that's documented everywhere: creating a breakpoint that only pauses execution when a particular expression evaluates to true.

显而易见的情况是到处都有记录：创建一个断点，仅在特定表达式的值为true时才暂停执行。

Using conditional breakpoints this way is nice when I'm trying to track down some weird behavior in a section of code that runs often, but whose behavior is broken only in the presence of specific combinations of data. A normal breakpoint would just pause execution every time and debugging would be tedious, but a conditional breakpoint allows you to pause only when the right data are present, so you can stop and look around. Nice.

当我试图跟踪经常运行的一段代码中的某些奇怪行为时，这种方式使用条件断点是很好的选择，但是该行为只有在存在特定数据组合时才会被破坏。 正常的断点每次都会暂停执行，调试会很繁琐，但是有条件的断点只允许在存在正确数据时暂停，因此您可以停下来环顾四周。 真好

But that's the mundane usage. Honestly, it's probably the least common way I use them. You see, conditional breakpoints are a scalpel. They're a monkey patcher's dream.

但这就是平凡的用法。 老实说，这可能是我使用它们的最不常用的方式。 您知道，条件断点是一把手术刀 。 他们是猴子修补者的梦想。

将变量导出到全局范围 (Exporting Variables to the Global Scope)

Have you ever been in a situation where you wanted console access to a variable defined locally in a function, but from an execution context outside the function? This happens to me all the time; I want to let my app load and run until an idle state, and then be able to inspect, say, properties or methods on some object locked away in a closure. Conditional breakpoints to the rescue!

您是否曾经想过通过控制台访问函数中本地定义的变量，但要从函数外部的执行上下文中访问控制台？ 这一直在我身上发生； 我想让我的应用程序加载并运行到空闲状态，然后能够检查锁定在闭包中的某些对象的属性或方法。 有条件的断点可以解救！

The main trick here is to use the lowly comma operator to make sure that the assignment doesn't evaluate as truthy, because that would cause the breakpoint to pause execution. Instead, the breakpoint expression evaluates to false and the app flies right through it and runs until idle, and then you can inspect the value in the console to your heart's content just by typing its name.

这里的主要技巧是使用低逗号运算符 ，以确保分配的结果不为真，因为这会导致断点暂停执行。 取而代之的是，断点表达式的计算结果为false ，应用程序将一直通过它并一直运行直到空闲，然后您可以通过键入控制台名称来检查控制台中与您内心内容有关的值。

Note: I make a habit of doing window.varName rather than just varName so I don't accidentally modify a variable that exists in an outer scope relative to the location of the breakpoint.

注意：我习惯于做window.varName而不是varName因此我不会意外地修改相对于断点位置存在于外部作用域中的变量。

Protip: in an ES2015+ enabled browser, export a series of variables quickly with shorthand property names: window.dealyBob = {var1, var2, otherVar}, false

Protip：在启用了ES2015 +的浏览器中，使用简写属性名称快速导出一系列变量： window.dealyBob = {var1, var2, otherVar}, false

Using the comma operator this way is the key to making conditional breakpoints sing.

使用逗号操作这种方式的关键是使条件断点唱歌 。

在不编辑代码的情况下添加日志 (Adding Logging Without Editing Your Code)

My most common use case for conditional breakpoints is logging. I know it's common among professional developers to poke fun at console.log-driven development, but being able to instrument your code without rebuilding or even reloading, watch everything run in real time, and get detailed diagnostic output is fantastic.

有条件断点的最常见用例是日志记录。 我知道专业开发人员在console.log驱动的开发中取乐是很普遍的，但是能够无需重新构建甚至不重新加载就能检测代码，实时观察一切，并获得详细的诊断输出，这真是太棒了。

What's wonderful about this is, the Dev Tools will save the breakpoints' associations with the file(s) in question (at least in Chrome, where I tend to work most often these days), so they're still there the next time I load the app in a different session, without me actually having to save any changes to my app code! This gives me a kind of runtime Aspect-oriented logging system that lives purely in the browser. How's that for separation of concerns?

这样做的奇妙之处在于，开发工具将保存断点与相关文件的关联(至少在Chrome中，这些天我通常最常在其中工作)，因此下次我仍在使用它们在不同的会话中加载应用程序，而无需实际保存对我的应用程序代码的任何更改！ 这给了我一种纯粹面向浏览器的运行时面向方面的日志记录系统。 如何分离关注点？

修改资料 (Modifying Data)

Say you have a bug where the repro is to have a particular combination of data loaded, and to get to that state you have a number of tedious steps to follow first. Not anymore! As a keen reader, I'm sure you noticed earlier that if you can modify properties on window to create new global variables in a conditional breakpoint expression, there's nothing stopping you from modifying anything else.

假设您有一个错误，即复制要加载特定的数据组合，并且要恢复到该状态，您首先要执行许多繁琐的步骤。 不再！ 作为一个敏锐的读者，我相信您之前已经注意到，如果您可以修改window属性以在条件断点表达式中创建新的全局变量，那么没有什么可以阻止您修改其他任何内容。

So go ahead and paste a bunch of JSON into a conditional breakpoint and assign it to whatever variables you need. Boom! Say goodbye to the tedious repro.

因此，继续将一堆JSON粘贴到条件断点中，并将其分配给所需的任何变量。 繁荣！ 告别繁琐的repro。

Protip: the comma operator allows you to chain more than just two statements together, so if you have a whole set of assignments to make, go right ahead and say: (var1 = x; var2 = y; var3 = z), console.log('overriding with', x, y, z), false

提示：逗号运算符使您可以将两个以上的语句链接在一起，因此，如果要进行一整套分配，请继续说： (var1 = x; var2 = y; var3 = z), console.log('overriding with', x, y, z), false

Related Protip: don't forget that you can set values on any global object from the console; if you have particularly large objects to use as overrides, or if you want to change the data a conditional breakpoint will use without having to modify the actual breakpoint, get thee to the console and say window.bigOverrideObject = {pasteYourObjectHere}, and then in the conditional breakpoint expression, var1 = window.bigOverrideObject, false

相关的Protip：不要忘记您可以从控制台在任何全局对象上设置值。 如果您有特别大的对象用作替代，或者想要更改条件断点而无需修改实际断点的数据，则将您带到控制台并说出window.bigOverrideObject = {pasteYourObjectHere} ，然后在条件断点表达式， var1 = window.bigOverrideObject, false

注入和测试新代码 (Injecting and Testing New Code)

Insightful reader that you are, you've likely realized that conditional breakpoint expressions are just JavaScript code that runs in the scope & context in which they're placed. If you can make assignments or write to the console in a conditional breakpoint, why not use one to test new application code? Yep.

您是位有见识的读者，您可能已经意识到条件断点表达式只是在放置它们的作用域和上下文中运行JavaScript代码。 如果可以在条件断点处进行分配或写入控制台，为什么不使用它来测试新的应用程序代码？ 是的

Insert a conditional breakpoint anywhere you like, and run whatever you want! There are a few limitations—for example, you can't return from the current function directly in the breakpoint expression—but for the most part, you can do whatever transformations or computations your app needs.

在您喜欢的任何位置插入条件断点，然后运行所需的任何内容！ 有一些局限性，例如，你不能return从当前函数直接在断点表达，但在大多数情况下，你可以做任何转换或计算你的应用需求。

This is where the monkey patching aspect comes in: you can combine all of these techniques and use conditional breakpoints to overwrite entire functions, even when they're inside a closure. Check it:

这就是猴子补丁方面的来龙去脉：您可以结合所有这些技术，并使用条件断点来覆盖整个函数，即使它们位于闭包中也是如此。 核实：

Pretty sneaky, sis! (warning: '80s kid reference)

姐姐 (警告：'80年代孩子参考)

Protip: your dev tools obviously aren't modifying the deployed app code, so this makes for a great way to try things in your production system without doing a whole build/deploy cycle. Be careful not to tweak things in such a way that they end up wrecking your production data, however!

Protip：您的开发工具显然不会修改已部署的应用程序代码，因此这是一种在不进行整个构建/部署周期的情况下尝试在生产系统中进行操作的好方法。 请注意，不要以使它们最终破坏您的生产数据的方式进行调整！

结论 (Conclusion)

I love conditional breakpoints. And now I hope you do too!

我喜欢条件断点。 现在我希望你也这样做！

PS: special thanks to my pal and fellow conditional breakpoint enthusiast Brian Sinclair for reviewing this article, and for the conversation that inspired it. His love for conditional breakpoints is truly unconditional.

PS：特别感谢我的朋友和有条件断点爱好者Brian Sinclair对本文的审阅以及对这篇文章的启发。 他对条件断点的热爱确实是无条件的 。

翻译自: https://davidwalsh.name/debugging-conditional-breakpoints

perl 调试 条件断点