The exception that proves the rule

by Michael S. Kaplan, published on 2008/07/04 03:01 -04:00, original URI:

Remember those posters that said "Today is the first day of the rest of your life"? Well, that's true of every day but one -- the day you die. -- Lester Burnham (Kevin Spacey)

Every rule has an exception.

Like the general rule that it is a bad idea to hard code strings in a call to MessageBoxW -- you should always load the string from resources so that your localizer has the opportunity to translate the text.

This is a very good and sensible rule, and it was just yesterday that several of us were reviewing bug descriptions that were entered to the bug database by a tool that detects such problems.

But while looking through the valid reports of bugs that various developers were going to have to fix, we found one case that is the exception to this rule.

This good and sensible rule.

Can you guess what it might be?

The one time that this rule isn't true?

Some people might think it is an ASSERT function. Good guess, but no. That isn't it.

The exception is when the error is something like this one:

Catastrophic Error: Unable to load message.

And the call comes after the attempt to load the error string in question fails.

This is a great exception to the rule.

I mean, is there ever a better time to point that we could hardly expect a developer to load that message from a resource....

Though to be honest there is a flaw in this specific description of otherwise unassailable logic.

Can anyone guess what that flaw might be?


This blog brought to you by(U+29ee, aka ERROR-BARRED WHITE SQUARE)

tballard on 4 Jul 2008 8:05 AM:

You're not telling the user about the original error?

Blake Handler on 4 Jul 2008 11:07 AM:

"The exception that proves the rule"

That phrase always amused me – when it's the exact opposite that is correct.

Theories are "validated" when experiments are repeated by many people who ALL verify the same experiment’s outcome.

If a different result occurs -- then the experiment would invalidate the theory.

So . . . ."The exception disproves the rule" (^_^)

GregM on 4 Jul 2008 9:55 PM:

I would hope that they tried to load the "catastrophic error" message from resources first, and only used the hard coded string if that string couldn't be loaded either.

One that truly can't be loaded from a resource is the one that says that the resource DLL itself can't be loaded (assuming that all localization is done in resource DLLs and the main application isn't changed).

Andy on 6 Jul 2008 8:10 AM:

Is the flaw that the program is taking itself just a teeny-weeny bit too seriously by proclaiming a "Catastrophic Error"?

Paulo Santos on 7 Jul 2008 3:41 AM:

I think that you can have at least 2 kinds of destinations for error messages: the user and the administrator.

If you something unexpected happens when you are trying to fetch an error message for the user, than this unexpected error should be shown to the Administrator and not the user anymore.

So, the user would see be a default error page saying something like "Sorry, unexpected error". And the Admin would see an error  "Unable to load message" and hopefully some more details.

Timothy Fries on 7 Jul 2008 5:55 PM:

>> That phrase always amused me – when it's the exact opposite that is correct.

Not necessarily.  If you consider the word "rule" to mean something more akin to "general rule"; then the very fact that the proving exception is, in fact, a truly exceptional situation does indeed validate the premise that the "general rule" holds as such.  After all, if the proving exception were a common case, it wouldn't be very exceptional; and in that case the original "rule" would lead you astray.

Rules were made to be broken, after all.

Rob Kennedy on 8 Jul 2008 3:30 PM:

Regarding "the exception that proves the rule," please see

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day