One of the simplest to understand, best practice of writing code (outside of maybe limiting # of lines in a method) is don’t create duplicate code. Having duplicate code leads to tons of maintenance issues as bugs are fixed in some places, and not others. Following this best practice, it’s very common recommended best practice to let your Plugin Base class logic handle catching and logging exceptions.
*Important Side Bar* Before going any farther, there are 101 ways to setup debugging in Visual Studio and in certain situations this doesn’t apply, but for the most part, I will assume that your Visual Studio Debugger is setup with most default settings still in place, including the “Enable Just My Code” option. Also, I don’t know everything about the VS debugger or C# debugger attributes, so if there is a better way, please let us all know. Alright, lets continue…
One of the problems this creates for those that have unit tests, is (more than likely) that when debugging a unit test, if the plugin itself throws an exception (NullRef anyone?) the debugger will stop execution at the throw statement in the plugin base, since that’s the last place that the exception is caught, before surfacing it to the application, normally CRM, in this case, it would be your test harness. This is rather annoying, since you don’t see the actual like of code the error occurred at since it was caught by the plugin base class when thrown. As the picture below shows, this gives 0 context as to where the exception has actually occurred without digging into the stack trace within the exception (as opposed to the Call Stack in VS)
With the equally less than helpful call stack:
So how do we get VS to stop debugging where the error happens, rather than at the plugin base exception handler logic? Enter “Debugger Attributes” to the Rescue!
There are quite a few “Debugger Attribute” classes in the System.Diagnostics namespace, but the one that makes most sense here is the DebuggerStepThroughAttribute (Or, if you have an open source project that is distributed as code (code gists, source only nuget packages, submodules, etc) or if you want to use the “Enable Just My Code” debugger option to be able to control if you can set a break point and debug or not, then the DebuggerNonUserCodeAttribute makes more sense.). By adding this attribute to your base plugin class that contains the throw (or method level if you so desire)
[DebuggerNonUserCode] public abstract class DLaBGenericPluginBase<T> : IRegisteredEventsPlugin where T: IExtendedPluginContext {
this will force VS to give the desired result:
Since the method handling the exception is “hidden” from the debugger, now the call site of the method that throws the exception, will be where the debugger stops. Above we can see the actual method call that resulted in the null ref exception was GetByName(), and below the exception call site is shown in the calls stack, so the path to the exception is easily navigated to:
But wait, what happened to the base plugin call site? Where did it go? It’s represented by the [External Code] line. It can’t be stepped into, or debugged without changing your debug settings or removing the attributes but it still shows up in the actual exception stack trace. So spend less time diving into the exception stack trace, and instead, allowing VS to put you on the actual line where the exception is actually occurring.
Happy Coding!
Posts
