Mardy (Posts about securitate)

Error handling and exceptions

Alberto Mardegan — Fri, 24 Apr 2020 15:07:51 GMT

Yes, this is yet another post in the internet talking about using exceptions versus error returns. The topic has been flaming up at my workplace for quite some time now, and I felt that writing a blog post about it during the week-end would help me focus my thoughts and give me time to explain my point with the due care. In case you didn't know, I'm against using exceptions for error handling (maybe having spent many years working with Qt has had an effect on this); that does not mean that I never write code using exceptions: I certainly do my good share of try ... catch when dealing with third-party code (including the STL), but you won't find a throw in my programs.

I'm not going to write here all the reasons why I refrain myself from implementing error handling using exceptions; I'd rather like to focus on the one I consider to be the major one, and which I rarely see being given the due weight in the debate.

And please note that this post is about C++ only; it may be that exception handling in other languages is designed in such a way that all my concerns are addressed (either by the language itself, or by common error handling policies).

Code safety

I was about to title this “Code readability”, but this is more about code verifiability, that is making sure that the code is correct and, ultimately, safe. As we all know, code is written once but read many times, and even if it's code you've written yourself, chances are that in a few weeks time you'll have forgotten several details about it; error cases and error handling are one typical thing that doesn't stick in our memory for long.

When I look at a small piece of code, such as the one that can fit into my screen, or which I can read from a merge request diff, I want to be able to ascertain that the code I'm looking at is correct. Let's look at some examples.

A `throw`-free project

assert(track != nullptr);

Car car;
car.setMaximumSpeed(90);
car.setName("Herbie");

if (!car.executeLap(track)) {
    log("Car failed to complete track");
    return false;
}

Path *path = car.getPath();
if (!path) {
    log("GPX path could not be retrieved");
    return false;
}

double temperature = car.engineTemperature();
double boundingRectArea = path->boundingRectArea();

I just made this up, so please bear with me if it doesn't make any sense. What I want to show is that code like the above has very few fault risks, if found in a project which bans throwing errors as exceptions: if we exclude out-of-memory errors, that are generally not handled to let the application crash (though you can always catch them if you like), the reader can easily verify that this code is safe. Coding style policies and naming conventions can guarantee that setMaximumSpeed() and setName() won't have a return value that needs to be checked, and all other method calls either return an error that our code is properly handling, or return some value. Of course, by just looking at this piece of code we cannot know if the engineTemperature() method has some other overloaded sibling which accepts passing a reference to a boolean and which could be used to detect an error; so, it may be that our code could be improved in that respect, if we had a look at the header files for the Car class — but this does deny the fact that a simple glance at this snippet tells us exactly what errors are handled and what could be going wrong.

Let's look at this code instead:

assert(track != nullptr);

Car car;
car.setMaximumSpeed(90);
car.setName("Herbie");

car.executeLap(track);
Path *path = car.getPath();

double temperature = car.engineTemperature();
double boundingRectArea = path->boundingRectArea();

If we continue on the assumption that we are working on a project which bans throwing exceptions, we can immediately say that this code is not safe: we don't know if the car successfully executed a lap on the track, and our process will crash if boundingRectArea() is invoked on a null object.

Enter the exception

In a project where exceptions are actively used, the code from the second snippet is not obviously wrong anymore: maybe executeLap() cannot throw any exceptions, or, if does, the caller of this snippet is catching the exception? In order to figure out whether this code is correct, I need to see the declaration of the executeLap() method, and hope that there's a nice noexcept in there; if there isn't, I have to look at its implementation, and recursively descend through all the methods it calls — at which point the safest attitude is just to assume that it can throw. But that's only half of the story, because once I accept the fact that executeLap() can throw, I need to check whether the exception is properly handled: I have to check the implementation of all the callers of my method, and if I don't find a catch there, I'll have to recursively walk up the tree of their callers.

And indeed even the first snippet, which looked so harmless when exception throwing was banned, suddenly becomes not obviously correct anymore: what if executeLap() or getPath() also throw an exception? You might say that it would be quite a silly thing to do, and I'd certainly agree; but it may be that indeed they don't throw any exceptions in their implementation, but some of the methods they call does.

A compromise: catch early, catch often

The obvious solution to the above issue is having a policy of handling exceptions right away, and explicitly rethrowing them (or even better, rethrow a different, more appropriate exception) up the stack:

assert(track != nullptr);

Car car;
car.setMaximumSpeed(90);
car.setName("Herbie");

try {
    car.executeLap(track);
    Path *path = car.getPath();

    double temperature = car.engineTemperature();
    double boundingRectArea = path->boundingRectArea();
} catch (std::runtime_error &e) {
    log("Car failed to complete track");
    throw;
}

What I can tell from the above snippet is that the code is handling errors, and this is somehow a relief. I'm sure some of you would suggest using a more specific catch clause, but for the sake of this example let's assume that this one is fine.

(Quick note: the above example does not catch std::exception, because that would also catch the std::bad_alloc exception which is typically thrown in out-of-memory situations; my advice is not handle it at all, unless you know what you are doing)

In real life, though, you might find that try-ing on a rather large block of operations is not enough: suppose that the Car methods all emit the same exception type, and that you need to handle them differently depending on when they occur. Then you'd need to split up the try into smaller blocks, and at that point your code won't look any cleaner than the equivalent code which uses ifs on return values. Of course if you own the Car class you could modify it to throw different exceptions, in order to keep more operations inside the try block and have specific catches at the end.

The big catch (pun intended)

Even once you've refactored your methods to get the best out of exceptions (where "best" is highly subjective, but let's assume that it just means that you are happy with your exception-throwing code), there's something that still bothers me, and that's exactly the same thing that proponents of exceptions use as a “pro” in their argumentations: the business logic of your code gets separated from the error handling. You get a nice block of pure logic, not cluttered with error checking, and a catch section (which I call “the big catch”) where error cases are handled.

I really don't see how that makes the code any more readable or safe: sure, the logic is not intertwined with error handling and might help focus on the expected flow of the operations (though, really, I do not think that normal brains have a problem skipping over if blocks), but that's hardly what I'm interested in when I want to check that the code is correct. Most of program errors and bugs lie in handling the edge cases and the abnormal situations, the seldomly taken code paths, and that's where I need to focus my attention.

try {
    operationA();
    if (value > B.maxValue()) {
        operationB();
    } else {
        operationC();
    }
    operationD();
} catch (ExceptionI &e) {
    ...
} catch (ExceptionII &e) {
    ...
} catch (ExceptionIII &e) {
    ...
} catch (std::runtime_error &e) {
    ...
}

When I see code like this one, I need to mentally build a mapping of “operationX() → possible exceptions” (which, unless exception naming is making this obvious, requires me to look at the implementation of the operationX() functions), and then mentally reconstruct the possible code paths in case operationX() fails, for each line of the try block.

Not seeing the errors right there, right away makes the correctness verification harder, which in turns means that the code becomes less safe. It will make you focus on the best case scenario, while ignoring all those annoying edge cases — too bad that 90% of the bugs are there.

Reading through the ISO C++ propaganda FAQ

I've been given a link to the C++ FAQ about exceptions, and unfortunately I read it. While there isn't much to argue on the technical side of it, it also carries some misleading statements, which might be true in absolute terms but don't let you see the big picture by not mentioning all that you need to know (which is the fundamental technique behind propaganda). An example is when they mention that eliminating ifs makes for more robust code, without mentioning that the same applies to all code branches, including exceptions.

Another argument that bothered me when I read it is the one about error propagation; this is the example they make:

void f1()
{
    try {
        // ...
        f2();
        // ...
    } catch (some_exception& e) {
        // ...code that handles the error...
    }
}
void f2() { ...; f3(); ...; }
void f3() { ...; f4(); ...; }
void f4() { ...; f5(); ...; }
void f5() { ...; f6(); ...; }
void f6() { ...; f7(); ...; }
void f7() { ...; f8(); ...; }
void f8() { ...; f9(); ...; }
void f9() { ...; f10(); ...; }
void f10()
{
    // ...
    if ( /*...some error condition...*/ )
        throw some_exception();
    // ...
}

The claim is that this code is more readable than the one with explicit error handling, because all the f2(), f3, …, f9() functions don't have to handle the error occurring in f10(). It is indeed a convincing argument, when presented in these terms, but is this really how our code looks like? In real life, you'll hardly have a chain of 1-liner functions, all defined next to each other in the same file. The moment that you realize that each one of these f_n() functions might be twenty or thirty lines long, and that they might be scattered over different files, and be called not just by f_n-1() but by any other function in the codebase, the picture does not look so rosy anymore: we get back to my main point of pain, that is that looking at the code of, say, f5(), I will not be able to tell if the errors thrown by it, or by any of the methods invoked by it, are properly handled.

Exceptions in APIs

A side note about projects using exceptions. I'm not really bothered when a library I need to use is throwing exceptions: having to write

try {
    Foo::fetch("http://example.com/resource.txt");
} catch (Foo::Exception &) {
    return false;
}

is not less readable or less safe than the code I'd write if Foo::fetch() returned an error code. I still do have a little complaint, because the library author has given himself the right to decide that a failure in his library should be considered a critical fault, whereas it may be that in my program it is an expected failure and using exceptions imposes a penalty which could have been avoided. But I digress.

As long as the library documents which exceptions are thrown, it is used by many people (which hopefully means that it has few bugs) and it is a library that I don't need to contribute to, wrapping some of its methods in try blocks is something I can live with.

One situation where I actually wish that libraries threw an exception is in out-of-memory situations; in that case, of course, I'd expect them to throw nothing else than std::bad_alloc, which is the exception emitted by the standard library in such situations. That allows the caller to decide whether to ignore the exception and have the process terminated (which is what I usually do, at least in desktop applications) or try their luck and handle the failure — the latter is not easy, but it can certainly be done.

This is one case where error returns can be problematic, because it's likely that your code would look something like

if (!Foo::open(fileName)) {   // suppose that this returns Error::OutOfMemory
    log("Failed to open " << fileName);
    return false;
}

and in this case there's actually a risk that your code is going to trigger an out-of-memory error in logging the message; this shouldn't be a concern in most cases, but I can imagine some situations where one might want to know which was the exact operation that first incurred in the out-of-memory failure.

So, I'm actually fine with new throwing. As for my code, my throw statement is actually spelt as return.

Looking out for ideas: federated / aggregated content

Alberto Mardegan — Wed, 17 Jul 2019 14:55:04 GMT

I was looking at TripAdvisor, some days ago. It's a very useful site, filled with user-generated advice and reviews, which has become almost a must for travellers. But I never like it when a private entity gets so much power over our lives (even if it's — currently — exercised in total fairness).

I would like to have a federated TripAdvisor-like network. I duckduckwent for a while, but I didn't find anything similar (if you know of some project of that kind, please let me know in the comments).

But thinking more about the issue, I realised that I probably wouldn't even bother to type my reviews into that site; I have a blog, so ideally I would like to have the option to write my review here, and then have the site import it. Technically, it could work with a webhook, or even a periodic check (real-time updates would not be a requirement here) over a URL I've linked to in my profile on that site. Then, in order for the posts to be imported, they would have to be entered in a standard format: maybe some keywords (or invisible HTML elements) could be used as markers for the content that need to be extracted from an otherwise ordinary blog post, or the relevant content could be replicated in a different format in the HTML headers (this, though, would require some additional work).

And while we are at it, why not extend this to other social networks? I use Mastodon, for example, and occasionally I send out a toot with a link to my latest blog post in there. But it would be much nicer if I could somehow set a special mark into my posts while composing them, to have them automatically tooted out on my account (this could probably be implemented as a standalone service, authorized to act on my Mastodon account — similarly to how the Mastodon-Twitter crossposter app works).

But I'm rather confident that I'm not the only one having this kind of needs, and that's why I'm writing this blog post: maybe someone out there has already found a solution, or has some more concrete ideas? If so, I'm all eyes!

Why you shouldn't encrypt all your private communications

Alberto Mardegan — Tue, 20 Nov 2018 17:18:00 GMT

I was at the LinuxPiter conference a couple of weeks ago, and among the many interesting talks, a couple were about cybersecurity, privacy, encryption. The main point of these talks was roughly this: end-to-end encryption is getting easier to setup, so we (the technical audience at the conference) can start protecting all our private communication and hopefully help bringing the technology to a state where it's more accessible to the masses.

The reasons why people want to encrypt their private communications are varied: sometimes it's about hiding one's communications away from an oppressive government or from big corporations; other times it's about avoiding personality theft or stalking; but in general, the core point is that it's my private communication, and no other eyes than mine and the intended receivers's should have any right to see it. And this sounds pretty reasonable indeed.

However, some reading into the history of the technologies used to achieve this result has left me doubting. And actually, as this article's title says, I've slowly grown convinced that I should fight the battle on the opposite front, and convince people not to pursue the goal of encrypting their private digital lives. Which will probably get you suspecting that I've gone out of my mind, to propose not supporting something that nearly the entire technical community recognizes as valuable. But if you bear with me a little longer, I'll try to explain.

Let's start with this quote by Edward Snowden:

“Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.”

I do care about my privacy and, furthermore, I'm not such a hypocrite to say that I don't have anything to hide: quite the opposite, there are plenty of things I don't want people to know about me. I'm not arguing against the right to one's privacy, and I do use encryption when storing sensitive data on my computer or when sending out passwords to people. And I've long stopped sharing bits of my private life on the big social networks, which I mostly use in write-only mode for spreading political propaganda (and I invite you to do the same, unless you have already left them: these places must die). What I am objecting to is mass encryption of all of your communications, just for the sake of making them inaccessible to everyone else.

I don't want to hide things from the government. I definitely want to hide as much as possible from corporations and other individuals, but I do want the state officials to be able to access any private conversation of any citizen. I do not want mass surveillance, but if there are serious reasons to suspect that a person could be involved in some crime, then I want the state to be able to look into the suspect's conversations — while exercising maximum care so that these are not leaked to the press and, in general, to people who don't need to know about them. Call me naive or an idealist, I still hold the state responsible for my own safety and the sole guarantor of justice. Should state officials abuse their position and either leak the private communications of the citizens or — worse — use them for blackmailing, this is something that should be investigated and punished, but I don't believe that it is the norm. Considering Snowden's revelations about the extent of the mass surveillance program in the U.S. and seeing how little of this information has been revealed or used by malicious state officials makes me optimistic in thinking that this is a secondary problem.

Surely someone could point out that not all governments are trustworthy: totalitarian regimes suppress dissent, while encryption could help the oppressed speak freely and organize themselves. The first part of the sentence is certainly true, but the second part reveals, in my opinion, a wrong evaluation of the reactionary movements. Let me explain it more clearly with one example.
My western readers would probably include Russia (the country in which I live) in the list of the “totalitarian regimes” I mentioned above; but you might be surprised to know that the West's favourite opposition character, the nationalist Alexei Navalny, who is getting jailed every other month for minor offences, is quite open in his criticism, and provocatively organizes actions that he knows will get him into trouble, with the goal of getting maximum visibility and exposing what he believes are unreasonable laws. If on one side there could be some value for revolutionaries to use encrypted communications during the initial phases of their action, on the other, the real change can only be brought forward with the involvement of the masses — which means one needs open talks.
And even if we limit ourselves to the early phases of the organisation of a reactionary plan, I do believe that using encryption carries the bigger risk of alienating one's potential allies, which were not part of the conversation, who might easily be led to believe (the conversation not having been released) that the participants in these secret talks were after some criminal plan or were getting support from some foreign country.

Picture this: at the airport security check (maybe in a country whose government you don't trust the least), you are asked permission by the officials to open your luggage for a search. If you refuse, they'll confiscate your luggage, but they'll let you return home free; if you agree, you'll be able to return home free, and with your luggage.

And we get to the real criminals. No matter how some politicians are abusing the topic for their own profit, it remains a fact that terrorism exists and terrorists operate in our cities. If we all encrypt our conversations, we practically preclude the security services from performing a screening which could help them focus their attention on potential suspects; and whether the terrorists encrypt their conversations has little impact: the very fact that a conversation is encrypted could raise some suspicion (which doesn't mean that the security services would hunt down everyone who uses encryption! — but their online behaviour could be monitored for some time).
Furthermore, I don't buy the story that these technologies are good because they can help those who fight against injustices in some remote oppressive country; on the contrary, I have a strong suspicion that the reason why these technologies are pushed forward it to protect the corrupted financial world from having their deeds exposed, here at home. Well, maybe that's not the goal, but indeed those people would benefit from it, at our expense.

Finally, let me spend a couple of words on encryption technologies, because I believe that their history matters and that we should be aware of who stands behind them. Suppose that you were a Russian dissident, and the GRU sponsored the development of some technology that promises full anonymity and secrecy; would you use it? I hope you agree with me, if I say that you'd have to be a complete fool to use it, no matter how many independent agencies have analyzed the technology and found it to be impenetrable. The lamb would never live in a house built for him by the wolf, no matter how comfortable or solid it looks like.
That's why, if I had to name one particular privacy enabling technology which I recommend you not to use, that would be Tor. Developed in the '90s by the U.S. Navy to be used by U.S. intelligence agents embedded in foreign countries, the Tor project is still being funded by the U.S. government and its usage is being promoted worldwide, in order to make it harder for foreign government to identify the American agents; because it goes without saying that, if the U.S. agents were the only people using Tor, then foreign security services would have a rather easy time spotting them. Now, if you are perfectly fine with the U.S. government being able to read your secret communications, by all means do feel welcome to use Tor. But if you are a dissident in either the U.S. or an allied country, be it a Western European country, Japan, Israel or Saudi Arabia, then I'd think twice before using it. And even if you lived in Russia, China or Iran, well, the same fact of connecting to Tor carries the potential risk of exposing you as a rebel or as a foreign agent.

That's why I don't encrypt my online conversations, and I don't strive to be anonymous online. No matter how bad the government we live in might be, I'm deeply convinced that the state is the only authority that can protect us; and if we don't trust it, or if we want to act against it, then we'd rather do it openly, suffering all the consequences that might arise, but having done all our best so that other people might find the courage to join our cause.