This whole courtroom is out of order!

22 08 2010

[Part I]
I’ve spent the last few days researching error handling in C++ [and in general really]; many a-battles have I found scattered around and I’ve gotten the impression that the entire topic is quite subjective, where one man’s Hellspawn-Demons are another man’s BFG.

I would like to start since by laying some groundwork and defining some ideas since through many of the sites/tutorials/chapters and debates I was left somewhat overwhelmed, the correct nomenclature seemed, I don’t know, disorientating. So without further ado let’s define my first item; the error.
An error is the difference between the expected result/state from the actual result/state

Any operation we use produces some results, or changes the state of an object. In order to create a proper logical flow we expect these operations to produce a desired result; functions and operations themselves expect some conditions to have been met before they too can produce expected results. Deviation from any of these expections will yield unpredictable and erroneous behaviour. Since the only person I allow to misbehave is my daughter I check for errors.

Next definition:
Error Checking
The act of defining an assumed condition and checking the actual result/state against it

Checking errors is a rather simple matter, we make an assumption, we write down an expected result, we run the function and use an if statement to make sure the result we got is the one we wanted.
void Window::Create()
  if (mCreated==true) { /*hmmm... do something*/ }
  mCreated=CreateWindow(); //WIN32 API call
  if (mCreated==false) { /*hmmm.. do something*/ }

There are two checks within this function, both check for errors yet they check for different types of errors. The first check which I’ve termed the PRECONDITION makes sure that the user does not call Window::Create() on an already created window; an error such as this can only occur when a programmer makes a direct call to the object via the code, this is a static logic error [as it makes no logical sense in terms of the code to call this function a second time on the same object without destroying the window first].

The second check partains to a different error and its condition is related to the execution of an external function [a function which crosses module boundries]. This is a runtime state error, an error which occurs because of external data. I’ve called this check the POSTCONDITION.

Let’s repeat this for a moment. The two errors in question are violations of either the PRECONDITION or the POSTCONDITION of the Create() function. Each violation in turn creates a different type of error. The errors are, in effect, generated at two different scopes and by two distinct user types.

Eh.. User types? What are those? I’m glad you asked…
Code User/Client
Application code can be used in two different contexts. The first of which is within the Debug state, whereas a Programmer writes execution code, whilst the second is Release mode; where an End-User receives and uses the application as is.

That is not to say that a programmer cannot be considered an end-user, nor that an end-user isn’t a programmer. But the approach to software builds should be with these mindframes. Where was I?

Ah yes. The ride is nearly over so I’ll now introduce two more concepts. Throwing exceptions and the ever ubiquitous Assert. Furthermore I’ll jump the gun and ruin the ending, in my system a PRECONDITION asserts while a POSTCONDITION throws an exception, but why?

The answer of course lies after some more definitions… These should be the last ones, hopefully…
Error Reporting
The act of informing the user and/or application itself that an error has occured

Error Handling
The act of dealing with the consequences of an error report as per user/client needs.

This post is getting long, the night is getting old and the dishes are, well staying dirty until I clean them, so I’ll finish with a last thought [the rest will be posted tomorrow, honest].

Error handling; we’ve found an error, a function has /*magically*/ reported it, what now? What now highly depends on the context in which the error was reported at, the most basic handling routine is to log the error with the most information you can recover about it to some log file for extraction [either immediately or later], that’s right, logging an error is NOT reporting it, nope, it’s a method of dealing with it and it isn’t [nor should it be] the only one. As I just said, other methods are highly contextual not just to the build-type but also to the user-type which has triggered the error. The rest will be explored/explained tomorrow, so stay tuned; same bat-time! same bat-channel!

“Oh would you like to swing on a star; carry moonbeams home in a jar; and be better off than you are”




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: