The Error Handling Design Pattern

The most prolific code smell, a code block that is problematic, found in most Code Reviews is missing or improper Error, Exceptions and Error Messaging. Delivered code generally works in a “Perfect World” but unfortunately we do no not live in a “Perfect World” and neither does our deliverables.

To Err is Human …

…… To Forgive, Divine

– Alexander Pope

……… But Not In Software Development!

The Modern Developer’s error Handling Design Pattern creates a reusable structure that can handle all conditional checks and code blocks that are suspected for an exception being thrown. The pattern also creates a vehicle for managing useful messages without “Magic Strings”, code embedded messages.

The Error Handling Pattern Components

The Class Model above shows the objects that create the Error Handling design pattern.

This pattern is dependent on the implementation of the Design Principle: Data Transfer Object Role Principal (DTORP). This principle is used to create a single Complex Composite Object as the Return of all Methods.

All Method Returns are Data

The Modern Developer uses Response DTOs to Encapsulate Lower Level Return Data from method calls. This data may be Stack Value Type Primitives such as Integers, Booleans, DateTimes, Decimals and even Strings or other DTOs acting as Aggregates for the enclosing Composite DTO.

Strings are technically not a primitive as they live on the Managed Heap, as Reference Types, and not the Stack, as Value Types, but for DTO reference purposes we consider them primitives. Collections can reside within the Composite DTO as Generic objects such as List<T> and Dictionaries.

The Class Method Return

The Object Model above shows the relationship between the lower level aggregate DTO and its parent Composite.

A class method, using the return type SubscriberInfoResponse, returns the SubscriberInfo Aggregate DTO encapsulated within the Composite DTO: SubscriberInfoResponse.

The Method Call Return Response DTO is Derived from the Abstract Class: ResponseCommon

This design pattern allows all Method responses to carry the Common Error Pattern Object Model.  This design pattern guarantees that a Success Flag, Error Handling Methods, and a possible collection of ErrorInfo DTOs, is always available for all calling Software Entities. 

The Calling Method can use a repeatable Error Handling Pattern for Conditional and Exception Handling that implements an Error and Information Messaging System

The Error and Information Messaging System

The Error Messages Produced by the Modern Developer’s Error Handling Design Pattern Must be Scalable and Extensible

The messages must have meaningful content that Developers, Quality Assurance Team members, and the End Users understand. These messages must be encapsulated outside of the calling error routine to eliminate class string messages: Magic Strings.  

Message encapsulation enables the Class to comply with the Open / Closed Principle (OCP). The Class must be Open to changing the message content but Closed to modifying the Class to make that content change.

The Messaging system can be an Application-centric solution such as Resource files, Global or Local. If required across multiple tiers in an Enterprise Architecture is should be a Database Messaging System solution.

The Messaging System serves Two Very Different Functions:

1. Program Error Messages for Identifying Conditional and Exceptions

2. User Interface Information and Error notifications

Program errors are designed to “Bubble Up’ from the lowest level of module abstractions and be seen by Technologists.

The highest level abstraction error handling should deliver messages as Information and Errors to the User Interface for consumption.

Program Error Messages should Never Reach the User Interface in any Environment other than Development and QA

The Modern Developer’s Error Design Pattern complies with this requirement by the using the “BubbleErrors” method in the base abstract ErrorHandling class.

The Highest Level Message will Always be Available for UI Consumption as Index: ErrorList.Count -1