关于使用反射和混淆的错误处理的建议 [英] Advice on error handling using reflection and obfuscation

查看:255
本文介绍了关于使用反射和混淆的错误处理的建议的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

 尝试
游标。 Current = Cursors.WaitCursor



Cursor.Current = Cursors.Default
Catch ex As Exception
MyAssembly.SystemError(MethodBase.GetCurrentMethod()。名称,ex.Message,MsgBoxStyle.Exclamation)
结束尝试

MyAssembly.SystemError 函数将错误记录到文件并显示一个消息框。



这样工作正常,直到我通过混淆运行我的代码,因为它将方法名称重命名为一些无法理解的字符(应该这样做),所以由 MethodBase.GetCurrentMethod()返回的反射的方法名称类似于无法理解的名称。



我已经开始将 MethodBase.GetCurrentMethod()。Name 替换为方法的名称,但是如果我重命名我可以(和做)的方法忘记更改错误处理名称。



有没有人有任何好的想法来处理所有这些?

解决方案

这是不幸的是混淆的一个缺陷,没有真正的解决方法(整个混淆点是隐藏和模糊你的信息尝试在这里显示)。



从可用性的角度来看,您应该尽可能地构建有意义的错误消息,例如无法找到文件{0} 。如果你模糊你的代码,那么你绝对不能依赖方法名称(或其他反映的信息)来构造错误消息。



BTW,将方法名称嵌入你的方法中的字符串这种方式本质上是解除了混淆器的工作。我的建议是:


  1. 首先更改错误处理,以预测可能发生的错误情况(例如文件IO或DB访问失败)和在每种情况下以合理的方式处理它,这应该阻止在错误消息中使用方法名称的需要。

  2. 如果您真的依赖于您的应用程序中的这些信息,那么只是不要模糊(我从来没有真的赞成模糊化)。

最后,这种错误处理你应该在 ThreadException 事件,但这完全是另一个话题! : - )


I use a standard error handling routine in my methods that looks like the following:

Try
    Cursor.Current = Cursors.WaitCursor



    Cursor.Current = Cursors.Default
Catch ex As Exception
    MyAssembly.SystemError(MethodBase.GetCurrentMethod().Name, ex.Message, MsgBoxStyle.Exclamation)
End Try

The MyAssembly.SystemError function logs the error to file and show a message box.

This works fine until I run my code through obfuscation because it renames the method name to some unintelligible chars (as it should do) so the reflected method name returned by MethodBase.GetCurrentMethod().Name is similarly unintelligible.

I have started replacing the MethodBase.GetCurrentMethod().Name with the name of the method but then if I rename the method I can (and do) forget to change the error handling name.

Does anyone have any good ideas to work with all of this?

解决方案

This is unfortunately one of the pitfalls of obfuscation, with no real workaround (the whole point of obfuscation is to hide and obfuscate the very information that you are attempting to show here).

From a usability perspective you should be constructing error messages from meaningful wherever possible anyway, such as "The file {0} could not be found". If you obfuscate your code then you definitely can't rely on method names (or other reflected information) to construct your error messages.

BTW, embedding the method name as a string in your method this way is essentially undoing the work of the obfuscator anyway. My advice would be:

  1. Firstly Change your error handling to predict what error scenarios might happen (such as file IO or DB access failing) and handle it in a sensible way on a per-situation basis, which should prevent the need from using method names in error messages.
  2. Failing that, if you genuinely rely on this information in your application then just don't obfuscate (I've never really been in favor of obfuscation anyway).

Finally, the sort of error handling that you are doing should probably be done in the ThreadException event anyway, but that's another topic entirely! :-)

这篇关于关于使用反射和混淆的错误处理的建议的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆