Was Andy Dufresne Guilty?

I’ve just watched the latter half of Shawshank Redemptionfor the third time in about two weeks. If you haven’t seen it, you should watch it. I expect film school, drama, and even classics students to be studying it far into the future. But that’s not my point. Rather, this time I got to thinking about why I like the movie so much. I’m going to go into that here, so spoiler alert. You have been warned.

Continue reading “Was Andy Dufresne Guilty?”

MasterCard Enables Fraud

Yes, the headline is clickbait. However, it is also accurate.

So I had some fraudulent charges on my MasterCard back in June. That did not unduly alarm me. I knew I needed to call my card issuer and disput the charges. I did so and they reversed them, cancelled the card, and issued a new one. All was well with the world. This is what should happen, after all. Alas….

TL;DR: Cancelling a card and getting a replacement after a fraudulent doesn’t necessarily stop the fraudulent charges due to some fuckwit at MasterCard thinking that “force billing” (allowing a merchant to obtain the new card number) is a good idea. My conclusion: “force billing” should be illegal.

Continue reading “MasterCard Enables Fraud”

Libraries are always good, right?

There is a pervasive belief in the software world that you should never re-invent the wheel and that an existing library is always the best solution. While there is some merit to the sentiment that re-inventing the wheel is often pointless or dangerous, I have recently come to the conclusion that this is not always the case.

Continue reading “Libraries are always good, right?”

The Greek Crisis, Money, and, Bitcoin

Over the past week or two, there has been a nontrivial amount of commentary on Bitcoin and Greece. Many commenters seem to think it is a prime opportunity for Bitcoin to go mainstream, or even go as far as being adopted as an official Greek currency. Others are much more skeptical, or downright derisive of the idea. I’ve discussed Bitcoin before (here, here, and here for instance). If you’ve read those posts, you’ll have a fair idea where I’m going to fall on this particular issue. Continue reading “The Greek Crisis, Money, and, Bitcoin”

Tips for Canvassers and Peddlers

We’ve all experienced this situation. You’re lounging comfortably in your easy chair watching some inane show on the television and generally relaxing. The door bell rings. Your first thought is to ignore it but you realize that your curtains are open so your caller knows you are home. So you groan, struggle to your feet, stumble to the door and open it, hoping it’s something important like the local constabulary enforcing an evaculation order you were not previously aware of. Alas, before you is a generic person wearing a badge of some kind and carrying some sort of clipboard. As soon as you open the door, he launches into his spiel. Continue reading “Tips for Canvassers and Peddlers”

Bitcoins and Currency

Much has been made of Bitcoins and other so-called digital cryptocurrencies. I remember how, in the early days, Bitcoin was supposed to be the cure for all the woes of modern fiat currencies and the central banking system. Even at the time, I failed to see the logic in that claim. I should mention that I have profitted some from Bitcoins, mostly by the fluke of having mined some when it was trivial to do so.

Before I get into Bitcoins, however, I should define a few terms. First, a fiat currency whose tokens have no real intrinsic value, or a negligible one. The only reason a fiat currency has value is because there is some authority that mandates its use for some process that is not optional. In other words, its value exists by fiat. The dollar (take your pick which one) has no intrinsic value – the coins and notes used to represent dollars and cents merely score keeping tokens made of base metals or paper or what have you. Furthermore, most of the dollars that circulate never actually physically exist in this day of digital transactions.

Central banks, on the other hand, are more complicated and simple at the same time. Wikipedia has a reasonable write-up on central banks over here. It’s easy to get bogged down in the details, though. Roughly, the central bank usually oversees the operation of commercial banks, manages interest rates (whatever that means, really), and often is responsible for producing the national currency.

Neither fiat currency nor central banks are problematic on their own, regardless what many fear mongers would have you believe. A fiat currency is arguably better than a commodity currency (gold, silver, copper, leaves, etc.) as long as there are sensible controls on how much is circulating. Central banks serve an important mediation role between commercial banks and also as a banker for the government.

Where the problem comes in is fractional reserve banking. I do not use the term “lending” because you cannot lend what you do not have. Basically, the fractional reserve system is an institutionalized fraud which allows commercial banks to “lend” money they do not have so long as they have a sufficient reserve level. This has the side effect of multiplying the money supply well beyond the amount put in circulation by the central bank. This sounds wonderful – more money is good, right? Wrong. For a good description of what is wrong with this system, head on over to Positive Money. Their take is UK centric but their illustration of the problem applies everywhere.

The practical upshot of the current money system is that without continual inflation, the economy will completely fall over dead because there will not be enough money to pay the interest on loans and therefore borrowers will default. As borrowers default, eventually the money supply starts shrinking making it harder and harder for the remaining borrowers to pay their obligations. You end up with a downward spiral of defaults leading to reduced money supplies, deflation, hoarding, and other problematic situations. In other words, the economy becomes illiquid and stalls. By continually increasing the supply of money circulating, this default spiral can be staved off. Positive Money notes how this is problematic in the current system in which the commercial banks are chiefly responsible for the total money supply.

The problem with inflation, however, is that it is basically stealing from the future to pay for the present. The dollar I put in a safe today will be forth far less in real value when I take it out in thirty years. At an annual inflation rate of two percent, that dollar will lose nearly half its real value over thirty years. Put another way, what you could buy today for $1.00 will cost you $1.81 in thirty years if inflation stays constant at two percent. If you start playing around with the mathematics and plug in the underlying cost of interest owed to the commercial banks, the implications become frighteningly clear. The current system is not sustainable and it is amazing it has not totally collapsed previously.

Enter Bitcoin. The creators of Bitcoin looked at the current situation and observed that inflation is bad and that we clearly need a currency with some sort of built in hedge against inflation. What if we create a currency that has an absolute upper bound to the number of currency units that will ever be created and prevent any central agency from having any control of the system.

That particular notion would make perfect sense in a steady state economy. A steady state economy is one where economic activity is neither growing nor declining. This is, of course, the only economic state that is actually sustainable, but that’s not the point of this discussion.

In the real world, economic activity is growing, on average, and it will continue to do so as long as the population continues to increase and demand for “stuff” continues.  That means, if you have a fixed currency supply, there will always be more and more stuff being chased by the same number of currency units. As the level of activity increases, the average prices must decrease if the currency available does not also increase. In other words, this situation ultimately has deflation built into it. While this is not necessarily bad in itself, it does cause some behaviour that is less helpful. Hoarding currency becomes profitable as it becomes more valuable over time, which, in turn, further reduces the currency supply, leading to further deflation. In short, even without a shrinking money supply (such as in the case of the default cycle mentioned above), the economy will eventually become illiquid.

The situation just described is exactly the situation with Bitcoin. What the designers of Bitcoin have created is not a currency but a scarce commodity akin to gold or silver. The same reason we abandoned gold and silver as currency units makes Bitcoin unsuitable as a general purpose currency. However, like gold or silver, it is useful for single transactions at a specifc moment in time, and, potentially, as an inflation hedge.

In other words, while I do hold a small number of Bitcoins, I do not believe they should ever become a mainstream currency. That would be more deleterious to the overall economic health of the world than the current central bank based fractional reserve system of fiat currencies. And that is saying something because the current system is so horribly broken that its ultimate collapse is almost certainly looming large on the horizon.

Exceptions Are Evil

Exceptions are evil.

Now that I’ve pissed everyone off, I can get on with explaining. Rather than talk in the abstract about this in the abstract, which is not helpful at all, I am going toss in an example or two. It is far easier to illustrate my point with examples in this case.

First, let me start by saying that the general concept of exceptions is not necessarily evil. Indeed, any program that is properly written must deal with exceptions in some manner, preferably without crashing randomly. Where things tend to go horribly wrong is when a programming language implements support for some flavour of exceptions. For instance, C++. It can obviously also go horribly wrong when a programmer messes up in a language that doesn’t implement any version of exceptions directly.

Leaving aside the syntactic problems with exceptions for the moment, let us consider what an exception actually is. The word would suggest an exception should be reserved for a truly unusual circumstance – something that should not normally happen. But what exactly does “unusual” mean?

Let’s examine the case of allocating memory on the heap. Ordinarily, this succeeds without a lot of fuss. But what happens if it fails for some reason, say there is no more memory available or the process’s address space is full? In C, the malloc() family functions return NULL to indicate this condition. The program then has to check the return value or simply crash when dereferencing the resulting NULL pointer. In most programs, running out of memory would be an exceptional condition so it would seem to be an excellent candidate for exceptions.

Let’s examine another case. Suppose you are opening a file to read some stuff in it. Now suppose access is denied or the file doesn’t exist. These are exceptions, too, right? Well, not necessarily. If you’re iterating through a list of possible file names to find a file that does exist, or which directory it exists in, experiencing a file not found situation is hardly an unusual circumstance, is it? Having a file with no access permission is likewise fairly normal on systems that support such things. If the file in question happens to be a critical part of the overall program that is running, that might constitute an exception since that is an unusual circumstance meaning that the program is incorrectly installed. But a missing input file to a compiler is likely not an exceptional condition and is one that the compiler will want to deal with directly.

On the surface the two situations above look the same, but they really aren’t. With the second example, the situations described are error conditions, but they are not unusual conditions. They are, in fact, ordinary conditions that are expected to occur in the ordinary operation of the system. They are, by definition, not exceptional.

One of the biggest issues I have with exceptions as they are implemented and used in modern systems is that the notion of an exception has been abused into a general purpose system for returning any error condition, routine or otherwise. I can possibly defend an exception on memory allocation failure, but I have a great deal of trouble accepting that an exception is the right solution when a file simply does not exist.

Modern systems have conflated error handling and exception handling. This may be partly due to the fact that without an exception mechanism, exceptions and ordinary errors have to be handled the same way – by an error indication from a particular call. The other source of the conflation is possibly due to the fact that many “software architects” do not understand why everything is not an exception.

All of that would be relatively minor, however, if the syntax for exceptions were not horribly verbose and insanely tedious to use, even when the language itself provides a solid bug-free implementation. The biggest problem is that this excess verbosity and extra boilerplate code encourages moving the error handling to a point distant from the actual source of the problem. The idea is that the ordinary flow of the code is easy to discover by extracting the error handling from within the main flow. However, this makes the flow non-obvious in the case of something like a missing file. If you do have a solution to a missing file, say by trying a different file, you can’t just continue where you left off if you have one big block and handle all the exceptions at once. Instead, you have to wrap everything that can fail with its own exception handling boilerplate. Now you have duplicated the exact thing you thought you could avoid by using exceptions in the first place! For instance:

result = somefunc();
if (result < 0)
{
    result = tryotherfunc();
    if (result < 0)
    {
        handle_error();
    }
}

if (do_something_with_result(result) < 0)
{
    handle_error();
}

if (do_something_else_with_result(result) < 0)
{
    handle_error();
}

The above is relatively clear. The precise mechanics of how handle_error() would have to work depends on the specific calls, of course. Let’s see what that might look like if we have a language using a “try { code… } catch ….” structure:

try
{
    try
    {
        result = somefunc();
    }
    catch (exception)
    {
        result = tryotherfunc();
    }
    
    do_something_with_result(result);
    do_something_else_with_result(result);
}
catch (exception1)
{
    handle_error();
}

That doesn’t look too bad, does it? But what if we need to do something different depending on which failure condition occurred with, say, do_something_with_result()? And suppose that do_something_else_with_result() might also throw the same exception for a different reason and we can handle that one too? Oops, now we need a try/catch block around each call. We can no longer get away with just the outer one. And for each exception we need to handle, we have to add another catch statement after the try block. It starts to get confusing rapidly.

Of course, you have to add some sort of if/else structure to do the same thing in the first example, too, but that is not going to be any more verbose than the try/catch structure.

There is another case here that should be examined, too. Let’s look at the case where you want to remove a file. Now suppose we are using the first style. If an error occurs, the call returns an indicator of such. If we are using the second style with exceptions, it throws an exception. Now suppose you don’t care if the file didn’t already exist. In the former, you can just ignore the condition. In the latter, you have to explicitly trap the exception and ignore it. The same situation often occurs when closing a file before exiting a program. Sure, errors can occur at that point, but what can you actually do about them? If exceptions are being thrown in that case, the do no good but you would still have to handle them or get mysterious unhandled exceptions at program shutdown.

There is another case where exceptions seem to be the best solution. Suppose the call is to some sort of implicit function, say an object constructor or an overloaded operator (overloading is evil too, by the way). In many languages, this is needed because objects can be constructed implicitly. That means there is no code flow that can trap an error return. The same thing applies to a destructor, which is often called implicitly. It is my contention, however, that if a constructor needs to do something that might fail, (resource acquisition, for instance), it really should not be doing anything implicitly. Instead, some sort of factory operation should be used to obtain a new object. In that case, explicit destruction is then obviously indicated. In short, if an object cannot be implicitly instantiated, there is no need for exceptions. Similarly, if you eliminate the notion of operator overloading, you eliminate the possibility of needing to fail randomly in expressions, too.

I should note that explicit construction is not actually horribly verbose in most cases, and certainly not terribly more verbose than what would be needed to express the static initializer anyway. Also, being explicit with an operation on an object does not preclude being able to chain operations together. It’s easy enough to put an object into an error state that can propagate through chained calculations and then be checked at the end. Sure, you might need multiple statements to chain the calculation together with explicit destruction being required and that might be a bit tedious, but it has the advantage of being absolutely clear what is going on.

And there is the final disadvantage of using exceptions instead of explicit instantiation and destruction, though this is not specific to exceptions per se. It is not at all clear whether a particular usage pattern is doing something dumb or not if you can just chain stuff together with implicit construction and destruction. Sure, you can create resource leaks with explicit destruction, but at least you can see if you are creating and destroying stacks of objects needlessly, and you can bail out in a controlled manner at any stage you like. It is also explicit that something which might fail is happening so you generally have a clear idea what failed if your program crashes at a particular location.

To this point, I haven’t even examined how the actual language exception implementation could be problematic, either. Suppose you have a language with explicit memory management like C++. Now suppose exceptions are objects. You throw an exception, but you have to dynamically allocate it somehow because it would go out of scope as the stack unwinds otherwise. How do you ensure the freshly minted exception gets freed correctly after the exception is handled? What if the object was a static object instead of a dynamic one (which also wouldn’t go out of scope)? What if memory allocation fails when creating the new exception object? Yowza! Things can go wrong in a hurry! Of course, in a language with automatic memory management, like javascript or java, this is much less of a problem. (Though what do you do if the exception object fails to initialize? Throw an exception?)

In short, in my never humble opinion exceptions are useless syntactic HFCS (high fructose corn syrup). They taste great but have at best dubious benefits and more likely are deleterious to maintainability or correctness in the long run. Even when well implemented using something less verbose than try/catch, they do not seem to be a substantial improvement over classical error handling. And, if they are only used for truly exceptional circumstances, the classical error handling would still need to be present for many circumstances (non-exceptional failures).

There is nothing wrong with explicit error handling inline in cleanly structured code. If you think you need exceptions to make your code clear, you are going down the wrong path.