Visual Studio - the Case for Catastrophic Failure! (Error handling: Fail early, fail safe)

-

Visual Studio, that erstwhile desktop development tool used by millions of Windows based developers since the late '90s, has been through many a revision.

Unfortunately, like any complex piece of software, some of these interesting and progressive revisions also involved the odd regressive bug, where the tool hit an unexpected state that it cannot handle.


Words fail to describe
 

Catastrophic failure!

Catastrophic indeed! In classic application developed software, handling 'undefined' situations that are not expected, leads to undefined behavior, where no one really knows how the system will continue to behave. Such situations pose a danger to any data involved, such as documents that the user is editing, since at the very least, the user may lost their current unsaved changes. Worse, if the program continues its imperative path (where the computer is blindly following instructions given by the original authors of the software), then the data may actually become corrupted, possibly beyond even an editable, readable state. So, the application developer protects the user and their data by throwing an exception: this halts the program in its tracks, preventing any further undefined behavior, and minimizing the chance of corrupting the user's data. Unfortunately, this results in ugly error dialogs appearing to the user, as shown here. Like many decisions in engineering, this is a trade off, here between immediate user-interruption and possible loss of unsaved data, versus continuing and possibly losing the data entirely due to undefined behavior. Ugly, but true!

There are some interesting alternatives to the imperative programming model, where the machine is following given instrutions in an exactly literal manner.
 
A simple alternative is to reduce the level of state in the application: following functional programming, where data is immutable and moves through functions, not modifying, but producing new copies. Application errors are still possible, but data damage can be minimized if data is treated not as a single replaced unit but a stream of immutable copies. Additionally, for the human who is writing the code, functional programming can be simpler to reason about, as it avoid side effects between program modules caused by shared modifiable state.
 
Possibly the field of AI can be extended more into application logic itself, and so applications may in future gain a better capability to deal with unexpected situations, such as mistakes in the design of the application, or unexpected application or environmental states, and 'learn' how to deal with the unexpected, or even avoid them re-occurring. Then, undefined behavior would up to a certain tolerance no longer be a problem to 'shut down' via error dialogs, but a normal part of application construction.

Comments

Post a Comment

Popular posts from this blog

null++ and its alternatives - NULL as an anti-pattern and some alternatives - stateless functional code

-
Image
  Notepad++ is a great and free text editor with many practical features, such as line-sorting, multi-file and directory find-and-replace, and excellent encoding support. However, programming is hard, and even the noble Notepad++ has been caught off guard in the war on bugs:  To NULL or not to NULL... A display full of NULLs is not that desirable, but on the other hand is better than random, uninitialized data, or worse, reading beyond assigned buffers into memory regions containing data this user is not supposed to see.  The history of NULL is a controversial one: it was, somewhat like JavaScript, cheap to implement at the time and seemed a good idea. However, notoriously, even the inventor of NULL considers the invention to be a mistake . At first glance, and when used in a very limited scope, NULL seems a sensible construct: a global kind of default 'this is not set' value, that is reliably detectable, as opposed to some random memory garbage. Issues arise when the NULL val
Read more

whoa! Chrome crash! - UX challenge of presenting a catastrophic failure

-
Image
A kind of California style, cool and casual way to tell the user that something truly bad has happened to the Google Chrome browser.   why ask? Although this is a "mere browser" and not the OS (there is still a difference, right?) - this does not seem so much different or better than Microsoft's prompting the user when the dotnet platform exhausts memory . Such an error seems unrecoverable - like a catastrophic failure, there is no choice to be made - so why ask? The user really does not have much choice - so why prompt? and why should the user need to decide what to do with your bug?
Read more

Windows Vista - reproducing 56.81 Shakespeares... - Operating Systems are complex and will always have bugs

-
Image
Windows has been around for quite a bit, and been thru several revisions. The Vista edition, like the Concord, looked impressive, but at times had difficulty flying. Here Vista is trying to show some volume controls (with a pretty basic hardware setup), and running into some difficulties: What causes this bug - who knows, and I suppose, who cares. Some kind of erroneous while condition, which can cause any imperative program to enter an inefficient, repetitive  state. Given the complexity of a piece of software such as Windows Vista (50 million lines of source code!). To put this in perspective, and at risk of comparing the art of C++ programming to that of 16th century literature (though at least in terms of age and fragility, there may be parallels), the entire works of the Great Bard (he of Hamlet) number 0.88 million lines. So we may reason that Windows Vista could have been composed by 56.81 Shakespeares.
Read more