Berlin CLA Summit 2016 Presentation “Error Handling for LabVIEW Architects” by Dmitry Sagatelyan

[Dmitry]

I gave this presentation at the European CLA Summit 2016 in Berlin. Slide Stack can be found on NI Certified LabVIEW Architects Community Forum (access limited to CLAs). This presentation is based on the one I gave at the BALUG meeting in November 2015, but includes new material such as “Pay Grade” Error Handling Strategy, benchmarks for Error Handling & Logging Overhead and an optimized “asynchronous” Logger Solution.

Abstract

Error Clusters are one of the most frequently used LabVIEW features. They did not evolve over the years, yet still provide adequate error handling support for smaller customer applications. However, developers working on larger size projects with emphasis on reusable code need something more flexible and scalable these days.

I will go over LabVIEW Error Handling scalability issues, how such issues may be addressed by custom Error Handling Extensions, and a scalable Error Handling Strategy used by the latest & greatest SOLID-compliant Arktur Technologies Error Handling Library (AKA Error Classters).

Error Classters use Error Classes instead of LabVIEW Error Clusters - which allows adding custom error data and altering error handling behaviors without changing existing code (Open-Closed Principle).  LabVIEW Error Cluster wires are used to propagate both - LabVIEW Error Cluster data and flattened Error Objects to Error Handling VIs without creating ripples throughout the application code. 

The (zipped) PowerPoint 2007 file has a fair amount of animations and is best viewed in Slide Show mode.

PDF file includes slide notes. To see notes either hover over an icon in the top left corner of a page (containing Notes) or right-click the icon and select “Open All Pop-ups” option.  Diagrams & images on slides with animations are stacked and may obscure images farther out along Z axis. Notes are essential for better understanding this presentation.

Enjoy,

Dmitry

[jon_mcbee]

Hey Dmitry,

This is a very nice presentation, I wish I had been there to see you give it in person.  Is there a reason why you didn't base the event logger on the mediator pattern, spinning up a topic actor for each sink type and using the global log idea for access?

Thanks again for the great content!

-Jon

[Dmitry]

Hey Jon,

Thanks for the kind words To address your questions:

1. There is no need in separate actors (one per Log Sink) since each message has to be logged to all active sinks
2. I have a simple worker loop as part of ArT_Async_Log class - upon receiving a message it executes a parallel loop on all sinks (slide #42). I think actors would be an overkill for such a simple task ...
3. I did not use my Message Broker component for a reason - Error Handling & Logging are a core component used in all (even the simplest and smallest of the projects). So I decided to minimize memory footprint, load and start-up time by using a light-weight, single-purpose worker loop instead of dragging Message Broker into each project ...

Cheers,

Dmitry