Sunday, October 28, 2018
As a Solution Architect I often review Microsoft Dynamics 365 custom server and client side code.
One of the most common rejects regards tracing and exception handling mechanisms, or their absence. Some code constructs may have empty Try/Catch blocks or none at all, other catch exceptions and just re-throw. As for tracing, code often contains debugging ‘aids’ such as alerts and debugger statements or no tracing notifications at all.
Why is this a reject?
Unhandled raw exceptions float to UI, confusing and frustrating users while exposing internal implementation details to potential attackers
System Administrator is unaware of custom code exceptions unless users decide...
Tuesday, July 15, 2014
In the previous post I described a solution to the business problem of logging & handling implementation level exceptions (presented in the first post of this series).
In this post, I will supply an actual solution, demonstrate common usage scenarios and other solution features.
Before I walkthrough usage scenarios, some implementation notes:
In order to support exceptions raised from transactional components (such as Plugin registered to pre/post operation stages), the LogException method in ExceptionManagement.cs file is using the ExecuteMultipleRequest class to execute the e4d_LogExceptionRequest request. As the ExecuteMultipleRequest instance is external to the Plugin transaction, it manages to create the Exception record...
Sunday, June 15, 2014
In the previous post, I described the business problem of logging and handling implementation level exceptions. In this post, I would like to suggest a solution. Before you continue reading, note that logging implementation level exceptions is up to your code developer. Although the solution supplies easy methods to log exceptions (to be demonstrated in part 3), nothing will be logged If your custom code does not use the solution components. Let’s start by defining some business requirements for the suggested solution: Support Microsoft Dynamics CRM 2013 of any deployment type Expose minimum exception details to...
Monday, June 2, 2014
In this 3-parts post I would like to suggest a general approach and solution for logging and handling exceptions in Microsoft Dynamics CRM 2013 implementations. By exceptions, I don’t mean Microsoft Dynamics CRM product core exceptions which occur from time to time. These are logged by various designated repositories (such as Event Viewer and CRM Trace) and beyond our reach anyway, certainly in Online deployments. I do mean unexpected events that arise from custom code written in both server and client side in most Microsoft Dynamics CRM 2013 implementations. These events are usually related to poorly written code,...