It’s easy to be exceptional…

So, I’m that guy. I’m the one who got booed (it was in good fun) at the CLA summit for proposing you leave automatic error handling enabled. Since then, I had a whopping 2% of the conference attendees come up and let me know they agreed with me. (OK, I’m rounding up to the nearest integer.)

I also had someone come up and ask me exactly what I meant, which was nice. I don’t feel I gave him a completely well-reasoned answer, however, which also gives me a chance to clarify exactly what I’m talking about for those that weren’t there.

The basis for my position comes from the book “Clean Code” by Robert C. Martin. It’s not a LabVIEW book (it actually talks mainly about Java), but it’s really just about programming in general. For those that haven’t read it, I strongly recommend you pick up a copy.

One of the chapters covers error handling. The position he takes is that errors are bad, and exceptions are good. He doesn’t establish a hard definition, but for the sake of my argument, we’re going to consider C++ the standard of reference. (Pardon the pseudo-code. I read C++ more fluently than I write it.)

In C++ you can return an error code, and that can be really useful.

int myFunction(...)
{
    err = 0;
    ...
    //something bad happened
    err = 123;
    ...
    return err;
}

int main()
{
    errStatus = myFunction(...);
    if(errStatus)
        cout << "You recieved error: " << errStatus;
    ...
}

But, if you forget to watch for that error, you will NEVER know it happened. All hell could break loose and your code will just continue along, oblivious to the world.

You can also throw an exception in C++.

void myFunction(...)
{
    ...
    //something bad happened
    throw 123;
    return;
}

int main()
{
    try
        myFunction(...)
    catch (int e)
        cout << "You received error: " << e;
    ...
}

In that case, you must also handle, or “catch,” the exception in the calling code. If you don’t, however, it will percolate up to the code above it, and so on and so forth.

At a very simplified level, it’s an error that you can’t accidentally forget about, and if unhandled, will ultimately cause your program to stop running and display a dialog or error message.

So, with that background, in case you missed it, here’s my slide:

So, the essence of my argument is that if you uncheck that box, you’ll end up in the same state as the first C++ snippet; anything you don’t explicitly look for is going to be lost.

If you /do/ leave it checked, you’ll be alerted if you don’t handle that “error” on some level, it will percolate all the way up to your main VI and cause a run-time error.

To be clear, what I’m /not/ saying is that you should USE automatic error handling. That’s a pretty bad idea; you should always do proper error handling. My point is, that if you accidentally don’t handle your errors properly, you WILL find out.

The counterpoints:

If I don’t wire the error out, it’s because I don’t care about it

OK, you might be the best LabVIEW programmer ever and never make a mistake. (The few people I’ve heard make this argument might actually be telling the truth.) For us mortals, however, this isn’t a valid reason.

It will block the execution of my code if the dialog box comes up. What if my operator is doing something super-important?

I have news for you. Whatever your operator *thinks* they are doing, well, maybe they are, maybe they aren’t. If you have an error that’s not being handled, you have no idea what state your program is in.

Also, when you build EXEs (which most of your deployments probably are), automatic error handling is turned off by default.  Personally, I think still think you should get the dialog. I haven’t tried it, but the following INI token should cause your EXEs to throw the dialog as if you were in the dev environment:

EnableAutomaticErrorHandlingRT=True

It hurts performance

Prove it. I have tried, and can’t repeatably do so.

Unit Testing will catch every possible error

See my the first counterpoint in this list. If you can write a unit test to cover every possible situation your code could ever be called in, this is fine. But, following this theory, that also means you never, ever release software with a bug in it. I don’t believe you.

I have VI Analyzer tests to find unwired error terminals

Good job. I still think you should leave it on, but I’ll shut up about it if this is your argument.

In Summary

So, I didn’t dive in to LabVIEW code showing what proper error handling actually is, but I think I’ve pretty well laid out the key points of my argument above. If you don’t think so, or you feel like you have another counterpoint, let me know in the comments below. Oh, and if you happen to agree with me, that would be cool to know as well.

I’ll try to make this the first in a series of posts about writing code cleanly in LabVIEW. This particular topic certainly not the best starting point, but I wanted to address this specific issue given its timeliness. I promise most of them won’t be this contentious.

And remember: It’s easy to be exceptional… just don’t make errors.