【发布时间】：2015-04-28 05:50:14
【问题描述】：
rails 4.2 web-console gem 是否完全替代了 better_errors gem，还是我需要查看每个的特性来确定我更喜欢哪一个？
【问题讨论】：
标签： ruby-on-rails better-errors-gem
【发布时间】：2015-04-28 05:50:14
【问题描述】：
它们不是一回事。web-console 甚至在它的自述文件中推荐 better_errors：
查看 better_errors 作为任何 Rack 应用程序的绝佳替代品！
web-console 的优势在于，您可以在文件或视图的任何位置启动控制台会话，调用 debug，就像 binding.pry（来自 pry gem）一直做的那样.
better_errors 是一个改进的错误屏幕，恰好在侧边栏上有一个控制台会话（如果您使用 binding_of_caller gem）。
IMO，您可以同时使用这两种宝石。无需选择其中一种。
【讨论】：
-
它们在为您提供调试控制台方面不是很相似吗？虽然您给出的报价不再在 README 中，但也许这是个好建议，将 better_errors 用于 Rack 应用程序，将 web-console 用于 Rails 应用程序？为什么我们要同时使用两者（严肃的问题，而不是拖钓）？另外，我相信我们现在调用 console 而不是 debug
-
@Marklar better_errors 有一些好处。它显示的错误页面更好，并提供有关当前状态的更好信息。另一方面，web-console 在每个页面上都提供了控制台，包括那些已经正确加载的页面。
-
better_errors 向 AJAX 请求返回有用的错误响应，并提供手动控制台来检查最近的异常，即使它发生在 AJAX 请求中。 web-console 没有这个，尽管它确实有办法让控制台从 Rails 代码中打开。 （对于更好的错误，您必须引发异常。）
TL;DR：better_errors 更好。
我不同意这里接受的答案。主要是因为建议的差异不是真实的。
在任何你想要的地方触发 better_errors 控制台总是很简单的，就像raise 'bang' 一样简单。你在你想要的地方抛出一个异常，一个控制台就会在那个上下文中启动。您可以在任何文件或视图中引发异常并在该上下文中获取控制台。
我不确定接受的答案是否暗示 web_console 不会在异常时触发，这就是他建议同时使用这两种 gem 的原因，但无论如何现在 web_console 确实也会在异常时触发。
因此，鉴于没有功能差异，首先，运行这两个 gem 没有意义。事实上，我预计会发生冲突，尽管这可能只是归结为首先捕获异常的人。
其次，真正的区别在于 better_errors 更好。看两人的截图。 web_console 只是标准的 rails 异常页面，下面有一个裸露的黑色终端。如果您想知道本地或实例变量，您必须使用控制台检查它们。 better_errors （至少在我看来）有一个更漂亮的页面，但更重要的是它显示了调用堆栈（带有紧凑或完整的列表），它为您提供了代码列表，它在控制台上方和控制台下方触发它列出了请求/本地/实例变量，这些变量通常可以解释问题所在，而无需在控制台本身做任何事情。这是一堆额外的、有用的功能，而且 web_console 没有任何遗漏（除非极简主义是你的包包）。
我不知道为什么 37Signals/Basecamp 或 Rails 团队决定合并 web_console 而不是 better_errors。也许有设计哲学/架构的原因，他们想要保持一定的距离，也许他们认为它功能太全而无法自动包含在内。有些人似乎认为 37Signals 更喜欢内部构建或可以内部获取的东西，这可能是唯一的原因。
自 Thiago 发布以来发生的其他变化是，正如 marklar 所说，您现在以 console 而不是 debug 开始 web_console，并且 web_console 在其 GH README 中不再建议使用 better_errors 作为替代方案。
【讨论】：