Advice on error handling using reflection and obfu

Question

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?

Answer 1

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! :-)