【问题标题】:Advice on error handling using reflection and obfuscation使用反射和混淆处理错误的建议
【发布时间】:2011-05-04 14:11:54
【问题描述】:

我在我的方法中使用标准错误处理例程,如下所示:

Try
    Cursor.Current = Cursors.WaitCursor



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

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

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

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

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

【问题讨论】:

    标签: .net vb.net visual-studio-2010 error-handling


    【解决方案1】:

    不幸的是,这是混淆的缺陷之一,没有真正的解决方法(混淆的全部意义在于隐藏和混淆您试图在此处显示的信息)。

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

    顺便说一句,以这种方式将方法名称作为字符串嵌入到您的方法中实际上是在撤消混淆器的工作。我的建议是:

    1. 首先更改您的错误处理以预测可能发生的错误场景(例如文件 IO 或数据库访问失败)并根据具体情况以合理的方式处理它,这应该可以防止需要错误地使用方法名称消息。
    2. 否则,如果您真的在应用程序中依赖此信息,那么就不要混淆(反正我从来没有真正支持混淆)。

    最后,您所做的错误处理可能应该在ThreadException 事件中完成,但这完全是另一个话题! :-)

    【讨论】:

    • 我同意你的最后一句话,但是,在他的情况下,他不能用属性(MethodNameAttribute="whatever")标记他的方法,然后在他的异常处理程序中读取该属性吗?跨度>
    • @Saif 是的,但是如果你这样做,那么对名称进行去混淆是一项相对简单的任务,那么为什么首先要混淆呢?
    猜你喜欢
    • 2011-11-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-11-25
    • 2015-12-22
    • 1970-01-01
    • 2012-01-14
    • 1970-01-01
    相关资源
    最近更新 更多