One classic topic for this kind of discussion, which came up recently at work, is the use of exceptions for error handling. Every modern programming language offers an exception mechanism for this purpose, and presumably it is there to be used. However, ever since they were first introduced, there has been a large and vocal subset of the community arguing that exceptions do more harm than good and you’ll be writing better code if you just use good old return values to report whether a method succeeded.

One representative example comes from Joel Spolsky, one of my favorite authors. Another oft-quoted article making the same arguments is found in the “Frequently Questioned Answers” by Yossi Kreinin. They both make the same basic points: exceptions do not reduce complexity but merely hide it, and when complexity is hidden people tend to forget about it.

These arguments have merit, but I still feel that (when properly used) exception handling delivers enough value to be worth the cost. So I am going to be arguing for the status quo here, for a change. Executive summary: the dangers of exceptions are real, but code readability trumps almost everything.

Let’s say that we have a method of, say, 15 lines of code. This method is straightforward and easy to read and to modify. I can understand at a glance what it does; it forms a clear picture in my mind which I can easily reason about. There is just one problem with it: We haven’t added any error handling yet. For which we have basically two options: use return values, or use exceptions.

If we use return values, our nice clean 15-line method will suddenly blow up to easily five times as large, with lots of conditional statements and lots of ugly, repetitive boilerplate code. Such code is annoying to write and to read, easy to make mistakes in, and very tempting to get sloppy with. Suddenly, I can no longer hold a mental picture in my mind of what the method actually does. I’d have to go through the code line-by-line and trace all the possible code paths. Even then, I am quite likely to miss some subtlety. And since the method is now too large to fit on a screen, I should refactor it into multiple smaller methods, which requires adding even more errorhandling boilerplate.

On the other hand, if I use exceptions instead, most of my methods will become only a little larger, and all of the errorhandling code will be nicely contained in one place where I can reason about it separately. The rest of the code stays nice and clean and easy to understand at a single glance.

“Aha!” say the exception skeptics (exceptics?). “But that reduced complexity is only illusionary! If every line of code in your program might thrown an exception, you still have an enormous amount of possible code paths to worry about — they’re just not explicitly visible in your source code anymore, which is even worse!

Well yeah, that’s true. I still have to worry about those exceptions even if I can’t see them. But the nice thing is, I can think about them, because we are now back in the scenario where I have just 15 lines of code which I can easily turn into a mental picture which I can reason about. I can look at that code and ask myself: “What happens if an exception is thrown on this line?” “Will the resource I allocate on line 4 be properly cleaned up in all possible scenarios?” “If this function fails because of an invalid input file, how will we recover from that?” And the big difference is that I can reason about these questions at a much higher level of abstraction.

It’s like the difference between an amateur chess player and an expert. When a novice player thinks about his next move, he works his way through the possible options as a computer would: “I could do this, but then my opponent will do either that or that. Or I could do this, but then she will do …” This is not a good way to play chess, since there are a lot of different combinations and the human brain is really bad at systematically working its way through such a huge decision tree.

An expert chess player, on the other hand, thinks at the level of strategy and tactics, rather than individual moves. “I am on the offensive, but my opponent has stronger control over the center field. It looks like I could attack over the left flank and win a few pawns, but I should probably do something about that exposed bishop first..” Only after analyzing the board at this high level, will the expert identify a small number of specific opportunities and threats to be investigated at the level of individual moves and counter-moves.

From a given starting position, the number of moves and counter-moves available to the expert is the same as to the novice. But by thinking about the game at a high level of abstraction first, the expert can dismiss the vast majority of possibilities at a glance, without conscious thought, and focus on the half-dozen interesting cases which need to be investigated in detail. It could happen that the expert overlooks some subtle trick which the plodding novice would have discovered, but the smart money will bet against it.

(As an aside, research has shown that experts are much better than novices at memorizing the position of the pieces of a chess board, but only when dealing with a position from a real game. When the pieces are placed on the board randomly, the experts are not much better at memorizing them than people with no knowledge of chess at all.)

I am hardly a chess master, but I’m fairly good at reading code. When I try to read a large block of ugly code where every “real” function call is followed by a dozen lines of boring error handling code, I feel like the novice chess player in the story above, missing the forest for the trees. When reading a nice clean piece of code where the error handling is provided through exceptions, I feel like the expert player, spending most of my time thinking at a higher level of abstraction. The complexity of the situation is the same either way, but now I have a mental picture of the situation which allows me to visualize it from different angles, dismiss all of the boring straightforward cases at a glance, and quickly zoom in on the ones which require my detailed attention.

At this point, assuming you’re still reading, you are probably either nodding along with me or you’re getting red in the face and starting to sputter in protest. If you’re nodding along, that likely means you belong to the camp which views programming as an essentially artistic activity, where intuition and the undefinable concept of ‘elegance’ play a big role. You believe that there is an unprovable, but very real, connection between the subjective beauty of a piece of code and the chance that it is correct.

On the other hand, if you’re sputtering and getting angry, you probably belong to the camp which feels that software development is an engineering discipline in which feelings and emotions have no place. Your standpoint is that if a piece of code has 200 different possible execution paths, then somebody should bloody well go over all of those 200 paths and verify that each of them is correct — anything else is sloppy and amateurish and would never be allowed in your team.

And to be fair, I have a lot of sympathy for that standpoint, as I like to think of myself as a left-brain type of person as well. In fact, if I were in charge of developing the control software for a nuclear reactor, I would change sides: I would disallow exceptions, make sure that all conditionals are written out explicitly, and then use a variety of formal proof techniques to guarantee the correctness of every single path through the code. My team’s productivity may be less than one line of code per day, but there will be no mushroom clouds on my watch!

At this point, the people in the second group puff up their chest and say, well maybe you think that your project is not important enough to be worth using proper software engineering techniques on, but I take pride in my work and all my code is written to the same level of quality as a nuclear reactor! Well, maybe. Good for you. In the meantime, I have a deadline to meet.

So, dear reader, to determine which of these two camps you believe yourself to be in: when was the last time your used mathematically rigorous formal proof techniques to validate your program’s correctness? Yeah, me neither. Well, since we have just found out which camp you are not in, you had better make sure that your code is readable and elegant enough to be able to reason about it intuitively. It’s the only chance you have of delivering reasonably bug-free code at an acceptable level of productivity.

(Oh, and adding some automated testing won’t hurt either way. As Donald Knuth once famously wrote: “Beware of errors in the above code; I have only proved it correct, not tested it.”)

And by digital cash, I do not mean lame stuff like Paypal, which is basically just an ordinary bank account to which you can send transfer orders. No, what I’m interested in is the real heavy stuff, whereby you have a digital wallet full of cryptographic “coins” which can be transfered from one party to another, without a single central entity keeping track of the contents of your wallet. Ideally, you want to be able to transfer such coins even off-line, without the central entity needing to be involved with every individual transfer.

There are a couple of basic problems with the idea of using bits as money, which any “crypto cash” system will need to find solutions for.

Probably the biggest one is non-technical: the fact that governments really hate it when you propose something like an untraceable, anonymous and decentralized currency which is not under their control. Ask Douglas Jackson, founder of E-Gold, who in this Wired article is painted as a naive but basically well-intentioned and idealistic guy who tried to create a currency for the twenty-first century but who ran afoul of a whole lot of government objections. But let’s ignore the political angle for now, and look into the technical obstacles.

The first technical problem is obvious: if my coins are just strings of bits, what is preventing me from spending a single coin multiple times, or minting my own coins?

And then there is an issue which is somewhere mid-way between technical and legal/practical: where does the money get its value from? Here in the real world, it used to be that money was backed by gold or silver: in theory, you could take your bank note to the bank and they would exchange it for a little sliver of precious metal. Nowadays, pretty much all money is fiat currency: it has value because the government says it has value, which works as long as we all believe that it does. The latter is a bit less intellectually satisfying than the former, but it does raise the interesting question of whether you could create a working fiat currency from scratch, without being backed by any government or central trusted organization.

When it comes to sophisticated cryptographic techniques for digital money, the work of David Chaum is the acknowledged gold standard (sorry). His digital money is a brilliant combination of pretty much all of the most advanced techniques in cryptography: blind signatures, commitment schemes, zero-knowledge proofs and lots more. Particularly brilliant is his solution to the “double spending problem” mentioned above. In his approach, people cryptographically sign digital money orders with their name when they receive them from the bank, but they sign them in such a way that the information can only be retrieved when a money order is spent twice. The spending (which can be done off-line) will succeed, but when the bank receives the same “coin” back through two different channels, it will not only know that cheating has occurred, but it can retrieve the name of the cheater! However, as long as you spend each coin only once, your anonymity is safe from the bank as well as from the people you exchange money with, even if they all work together!

Chaum’s work requires some seriously advanced crypto, though. In the book Future Imperfect from my favourite author David Friedman, there is an alternative scheme which is a lot less sophisticated, but just as elegant in its impressive simplicity. Here is the entire system:

1. The bank gives out coins, which are simply large randomly-generated numbers.
2. When you receive a coin, you immediately send an (anonymous, encrypted) message to the bank, requesting that the coin’s number be changed to a different random value generated by you. You include a transaction code which is another random number.
3. If the bank can indeed find the original number in its database, it exchanges it for your new number, and publishes the transaction code in a public place so that you can verify that the coin you were given did indeed exist, and has been assigned the new number which only you know.
4. When you walk into the bank and present them with the new number, they will exchange it for, say, an amount of gold matching the value of the coin.

That’s all!

It’s not quite as secure as Chaum’s system in all directions. The system can be used off-line, but only if the payee trusts the payer to give him a real coin. The bank cannot breach your anonymity, but it can cheat by refusing to honour a valid coin. Even in the case of an on-line transaction, if the payee claims that the payer did not give him a valid coin, there is no way for an outsider to determine which of the two is telling the truth. But within these limitations, the basic functionality works and it’s a rather impressive achievement for a system which is so trivially simple that you could explain it to your ten-year-old nephew.

If you’re looking for a nice little intellectual challenge, think about Friedman’s proposal a little further. Identify the various practical problems with it, and see if you can come up with a solution for each of them, using basic crypto techniques such as symmetric and asymmetric encryption, digital signatures and secure hash codes.

Now, in the above approaches, the assumption is that there is still a central bank, trusted by all parties, which gives out the money and which gives that money its value by pledging to exchange it for some real-world valuable material such as gold, or perhaps simply by linking it to an ordinary bank account containing ordinary government-backed euros or dollars.

Bitcoin goes even further: it proposes (there exists a technical implementation, but they’re not really pretending that it’s ready for real-world use) a form of digital money which is completely decentralized: there is no central entity, anybody can create money and then spend it. As the FAQ explains it:

What is Bitcoin’s value backed by?

Bitcoin is valued for the things it can be exchanged to, just like all the traditional paper currencies are.

When the first user publicly announces that he will make a pizza for anyone who gives him enough Bitcoins, then he can use Bitcoins as payment to some extent – as much as people want pizza and trust his announcement. A pizza-eating hairdresser who trusts him as a friend might then announce that she starts accepting Bitcoins as payment for fancy haircuts, and the value of the Bitcoin would be higher – now it would be backed by pizzas ”and” haircuts. When Bitcoins have become accepted widely enough, he could retire from his pizza business and still be able to use his Bitcoin-savings.

That seems to make sense — money is basically a system of transferable IOUs whereby the participants agree to cover each other’s debts. However, if anybody can create Bitcoins and spend them anonymously, how can they ever be made to make good on their debts? And even without anonymity, what prevents me from creating more Bitcoins than I will ever be able to honour and then living like a king until the day of my death? Somewhere, it seems, there has to be a mechanism to create some artificial scarcity in order for the scheme to work.

Bitcoins proposes to solve this problem by making each coin represent a proof of work: creating a Bitcoin requires a large amount of CPU power; anybody who receives a coin from you can verify that you have performed a very complex and time-consuming calculation. Coins are linked together and there is a peer-to-peer system to verify that coins are not being double-spent. As with Friedman’s approach, you can accept coins off-line if you want but then you will need to trust the payer to not deliberately cheat on you.

This way, the amount of Bitcoins in the economy is limited and grows predictably, which are two very important requirements for a usable currency. Using CPU power to back the money’s value is of course completely arbitrary, but in principle that is not an impediment for a working currency. As with a conventional fiat currency, once the pool of people willing to accept the money is large enough, it is resistant to occasional cheaters; anybody who refuses to play along is hurting themselves more than they are hurting the people who partake in the system. Obviously, getting to that point is the difficult part.

By the way, if you think that the above schemes are not secure enough to work in practice, what would you think of the following system?

• Your bank account is represented by a single sixteen-digit number, which remains the same for several years.
• Anybody who knows this number can use it to withdraw money from your bank account.
• Making a payment consists of giving the number to the person you want to pay. So if you want to purchase something at a gas station, for example, you show a card with the number to the gas station attendant, after which he knows your number and you will have to trust him not to abuse it.

That must be the most horrible system anybody could possibly come up with, right? If you proposed this in an introductory computer security class for high-schoolers, your classmates would laugh you out of the room. Nobody with an ounce of common sense would every use such a horribly botched system for anything, let alone for making payments over the Internet, right?

And yet what I am describing here is, of course, the humble credit card.

I do not expect any of the cryptographic systems described above to become popular any time soon. But the most likely reason for their failure will be a combination of chicken-and-egg effect (nobody wants to use a currency which nobody else uses) and the first, non-technical problem mentioned at the start of this article. Nonetheless, it is awfully cool to consider what is possible in principle, and a good mental exercise to consider the various practical objections and try to come up with solutions to them.