尝试…赶上块感染
我正在为一家公司开发一套Excel加载项。 我之前没有做过插件，所以我对一些错综复杂的东西并不熟悉。 在交付我的第一个产品后，用户遇到了我在testing期间没有遇到/遇到/注意到的错误。 另外，我在Visual Studiodebugging环境中难以再现它们。
我完成了一个轻量级的日志logging课程，该课程接收来自程序各个部分的消息。 该scheme并不是很大，所以不是很多工作。 但是我最终得到的结果几乎是每一行代码都包含在Try … Catch块中，这样我就可以logging在用户环境中发生的事情。
我想我已经足够体面地执行了，我尽量避免将调用包装到其他类或模块中，而是把这个块放在调用中，这样我就可以更准确地识别谁在投掷，而且我什么也没有吞下去，我总是把我logging了我所感兴趣的信息之后的例外。
我的问题基本上是这样吗？ 有没有更好的方法来解决这个问题？ 我是否在基地？
快速编辑：重要的是，它确实工作。 我能够确定这个错误并解决它。
不，你没有离开基地。 我相信这是编写加载项时处理错误的唯一方法。 我正在销售使用此模式的Outlook加载项。 一些笔记虽然：
-
您只需要包装顶层方法，直接暴露给用户界面或由其他事件触发。
-
确保您的日志例程以recursion方式遍历Exception树，同时loggingInnerExceptions。
-
而不是重新抛出exception，你可能会考虑显示某种错误forms。
然后对这些笔记的一些评论：
-
我相信你明白这一点，但是你的评论“几乎每一行代码都被封装（…）”让我想要强调这一点。 但是，是的， 所有的代码应该最终在一个
catch (System.Exception)– 阻止，以便您可以logging您的exception。 我完全不同意格雷格说这是“危险的”。 什么是危险的是不处理你的例外。 -
如果你这样做，我不认为你需要“避免包装调用其他类和模块”，如果我正确理解你。 我已经发布了一个方便的扩展方法GetAsString，它允许我logging我在github上需要的东西。
-
在Outlook中，如果一个exception冒泡到Outlook本身，您的加载项可能会被禁用，甚至可能会导致Outlook崩溃，如果它发生在后台线程上。 在Excel中不一样吗？ 因此，我竭尽全力不让任何例外。 当然，您需要确保您的应用程序可以在此之后继续运行，或者允许正常closures。