{ "componentChunkName": "component---src-templates-post-page-js", "path": "/2019/error-handling-introduction", "result": {"data":{"site":{"siteMetadata":{"title":"Solid Abstractions","siteUrl":"https://solidabstractions.com","twitterId":291334023,"author":{"fullName":"Julien Hartmann","profileHtml":"I am an open-source de­vel­op­er, for­mer IT con­sul­tant with a pas­sion for new tech­nol­o­gies. I be­lieve the role of an en­gi­neer is to em­pow­er peo­ple, by as­sem­bling sim­ple, re­fined de­signs.\n","links":[{"url":"https://github.com/spectras/","name":"github","title":"GitHub"},{"url":"https://stackoverflow.com/users/3212865/spectras","name":"stackoverflow","title":"StackOverflow"},{"url":"https://www.linkedin.com/in/julienhartmann/","name":"linkedin","title":"LinkedIn"}],"profilePicNode":{"original":{"src":"/static/profile-pic-301a9cbe7b572c3e7910c9717d2b3bcd.jpg"}},"url":"https://etherdream.org/about"}}},"markdownRemark":{"id":"02c2797f-c769-5acf-8116-5d4bbd0e0df1","excerpt":"","html":"
  1. → Get the main functionnality working.
    2. \n
  2. → Realize that anything unexpected crashes and burns.
    3. \n
  3. → Add some band-aid where it hurts the most.
\nIn this series, we cover the basics of correct error handling,\nso it is no longer an afterthought.\n

--- excerpt ---

\n

Error handling is a recurrent issue in beginners' and not-so-beginners' code.\nIt is often an afterthought. The typical flow goes like this:

\n\n

In this article series, we will cover the basics of error handling and how it relates\nto proper abstraction levels for building robust software.

\n

A short typology of errors

\n

An error is a normal and regular event during the life of most programs.\nIt happens whenever an assumption it made turns out to be wrong.\nFor instance, it tried to open a file, but the file does not exist, or it sends data\nto a remote server, but the laptop has lost Wifi signal.

\n

We can split errors on whether the condition that is not met is expected\nto happen.

\n

Unexpected errors

\n

Ooops, did not think it could happen!

\n

Whenever an assumption made by a piece of code turns out to be wrong\nand the developer did not anticipate it could, it is an unexpected error.\nThe program can react in one of two ways:

\n

Undetected, unexpected error

\n

The progam is oblivious and keeps going. This is the most problematic case.

\n
\"This
From K.C. Green's gunshot webcomic.
\n

If an assumption turns out to be wrong, it means the program is in a state\nit was not intended to be in, ever. Therefore, the basis upon which its logic\nis built is no longer correct. Which means its result is very likely to be\nincorrect, too.

\n

With unexpected state come unexpected consequences.

\n

As we do not want unexpected consequences, we must detect unexpected state as soon\nas it happens. To that effect, we must make our expectations explicit,\nso that the failure is detected.

\n

Detected, unexpected error

\n

An assumption unexpectedly turns out to be wrong. Fortunately, the assumption was made\nexplicit, so the program crashes immediately.

\n
class SavingsAccount:\n    def withdraw(self, amount):\n        assert self.balance >= 0\n        # proceed with withdrawal
Assertions are a common way to detect unexpected errors, such as invariant violations.
\n

In this example, we have a savings account. Its balance cannot, by definition, be negative.\nIn more formal wording, this is an invariant of class SavingsAccount.\nBy making this assumption explicit, we will trigger an immediate crash should self.balance\nbe negative.

\n

“But data will be lost.”

\n

If we reach a point where we have in our system a savings account with negative balance,\nsomething has already gone horribly wrong and our data is already corrupted.\nWe want our program to crash and we want it to crash now:

\n\n

It is better to crash quickly and cleanly than to loose more data.

\n

The implication of assertions is that such an error cannot be recovered from, it is a defect\nin the program, that must be fixed by a person.

\n

Expected errors

\n

When we anticipate the possibility than one of our assumptions might be wrong in\nan otherwise correct program, and we know a way to deal with it properly,\nwe have an expected error.

\n

Expected errors normally happen at the boundaries of interfaces, where a component\ntalks to another component. This could be, another part of the program, the operating\nsystem, a remote server or some hardware component.

\n
def load_settings(path):\n    with open(path) as fd:\n        settings = json.load(fd)\n    return settings
This assumes way too much.
\n

This example makes many assumptions:

\n\n

We notice those assumptions depend on external concepts and entities. Which means\nwe should reasonably expect them to fail in perfectly valid circumstances,\nand this should be handled gracefully.\nDepending on the context and specific error, this can mean:

\n
Recovering

Our code runs an alternate logic path to reach requested behavior. For instance, here,\nif opening the file fails, it could fall back to default settings.

def load_settings(path):\n    try:\n        with open(path) as fd:\n            return json.load(fd)\n    except (OSError, JSONDecodeError): # we target specific errors\n        return DEFAULT_SETTINGS
Propagating the error

If our code is unable to handle the error condition at this level, it can propagate it to\na higher level, which will then choose how to handle it best. Possibly, such an error can\npropagate all the way to program entry point and terminate the program.

This is default behavior of python exceptions, so our code in Fig. 3 does this.

Converting the error

The error as it arises in our code might not be meaningful outside of it. It might pertain\nto an implementation detail that should not be exposed.

For instance, our load_settings function is meant to encapsulate the details of settings\nloading. We use json.load, which will generate a JSONDecodeError if the document is\ninvalid. If we propagated this error to callers, we would expose internal details\nto them, breaking the encapsulation. To avoid this, our load_settings function should\nconvert the error into another error, using higher-level semantics.

def load_settings(path):\n    try:\n        with open(path) as fd:\n            return json.load(fd)\n    except JSONDecodeError as err:\n        raise ConfigurationError('User mistake in settings') from err
\n

Errors Summary

\n

So you are standing in front of a piece of code, evaluating it line after line, statement\nafter statement. For each and every expectations that it makes, the following diagram\nshould help picking the appropriate action:

\n
\"Error
Error handling decision tree
\n

This whole decision happens within one single function, on every expectation it makes. One\nkey part is the final step, at the very bottom: as soon as we propagate an error, we\nmust ensure it is properly handled one level higher up the chain of callers. And then at the\nnext level, and the next level, until either it is recovered from or it reaches the top of the\nchain, at which point the supporting environment will usually invoke its default handlers,\ntypically printing an error and terminating the program.

\n

We take note, however, that though we outlined the decision process, we have not answered\ntwo crucial questions:

\n\n

The key to answering those is keeping levels of abstraction consistent. That will be the\nfocus of the next post in this error handling series.

","fields":{"isPage":false,"slug":"/2019/error-handling-introduction"},"frontmatter":{"title":"Error Handling part 1: Introduction","classname":null,"date":"2019-02-19T00:00:00.000Z","formattedDate":"February 19, 2019","isoDate":"2019-02-19T00:00:00+00:00"},"headings":[{"value":"A short typology of errors","depth":1},{"value":"Unexpected errors","depth":2},{"value":"Undetected, unexpected error","depth":3},{"value":"Detected, unexpected error","depth":3},{"value":"Expected errors","depth":2},{"value":"Errors Summary","depth":2}],"image":{"original":{"src":"/static/gunshow-46970d17bbd378c94e8f9da96b1a5258.png"}},"series":{"name":"software","fullName":"software engineering","fields":{"slug":"/software"}},"tags":[{"name":"code","slug":"/tag/code"}]}},"pageContext":{"series":"software","slug":"/2019/error-handling-introduction","previous":{"fields":{"slug":"/2018/testing-aiohttp-client-part-2"},"frontmatter":{"title":"Unit Testing aiohttp Clients - part 2","series":"python"},"tags":[{"name":"code","slug":"/tag/code"},{"name":"testing","slug":"/tag/testing"}]},"next":{"fields":{"slug":"/2019/error-handling-levels"},"frontmatter":{"title":"Error Handling part 2: Abstractions","series":"software"},"tags":[{"name":"code","slug":"/tag/code"}]},"seriesPrevious":null,"seriesNext":{"fields":{"slug":"/2019/error-handling-levels"},"frontmatter":{"title":"Error Handling part 2: Abstractions","series":"software"},"tags":[{"name":"code","slug":"/tag/code"}]}}}, "staticQueryHashes": ["1733002695","4006707078"]}