I’ve used a few different error handling techniques since university.\nOver the last few years a couple of other options have appeared.\nLets take a simple problem and see how it works with all of them.<\/p>\n\n\n\n
Let’s say we want to read a text file containing a list of dates and return them.\nThe file looks something like this:<\/p>\n\n\n\n
Date list\n5\n2001-04-13\n2005-03-23\n2011-11-01\n2022-03-30\n2024-07-15<\/pre><\/div>\n\n\n\nThat is: a fixed header, the number of dates to expect, all of the dates line by line.\nThis covers the basics that you might find in any file type:\nfixed items, values that control later parsing, values with detailed formats.\nThis is probably a file produced by a program,\nit outputs the number of items to expect from the list.\nFor a human produced file I would have an arbitrary sized list with a terminator,\nthat’s easier for someone to write.<\/p>\n\n\n\n
In these example programs I’m going to assume I have access to whatever functions I want.\nI’ll try to make them obvious and describe their behaviour if necessary.<\/p>\n\n\n\n
No error checking<\/h2>\n\n\n\n
Ignoring the problem is the easiest way to go about things.<\/p>\n\n\n\n
std::vector<Date> ReadDates(const std::string& filename) {\n auto* file = FileOpen(filename, "r");\n \n std::ignore = FileGetLine(file);\n \n uint32_t count = ParseUint32(FileGetLine(file));\n \n std::vector<Date> dates;\n for (uint32_t i = 0; i < count; i++) {\n dates.push_back(ParseDate(FileGetLine(file)));\n }\n \n FileClose(file);\n return dates;\n}<\/pre><\/div>\n\n\n\nThis is as simple as we can get.\nEach part of the header is read and assumed to be correct.\nIf there are any problems it’s unclear what the result would be.\nThe best you could hope for is an empty date vector, at worst a crash.\nYou don’t really know.<\/p>\n\n\n\n
I’ve deliberately used a old-fashioned approach to
FileOpen<\/code>.\nIf you’re usingC++<\/code> then you should use astd::filestream<\/code> which will close automatically in the destructor.\nIt will make this and every other example easier and shorter.\nHowever some languages don’t have destructors.\nThey might use with-statements or defer keywords instead.\nI went with theFileOpen<\/code> approach just to leave something annoying that had to be cleared up at the end.\nThat’s often the way with error handling.<\/p>\n\n\n\nSingle return<\/h2>\n\n\n\n
An easy way of dealing with errors is to have your functions return an error code or\nsimple a success \/ fail boolean.\nOne way to do is to focus on the successes first and leave the failures until the end.<\/p>\n\n\n\n
bool ReadDates(const std::string& filename, std::vector<Date>& dates) {\n bool success = true;\n auto* file = FileOpen(filename, "r");\n if (file != nullptr) {\n \n std::string headerLine;\n if (FileGetLine(file, headerLine) && headerLine == "Date list") {\n \n std::string countLine;\n uint32_t count;\n if (FileGetLine(file, countLine) && ParseUint32(countLine, count)) {\n \n for (uint32_t i = 0; i < count; i++) {\n std::string dateLine;\n Date date;\n if (FileGetLine(file, dateLine) && ParseDate(dateLine, date)) {\n dates.push_back(date);\n }\n else {\n LogInfo("Failed to load date line {}", i);\n success = false;\n }\n }\n }\n else {\n LogInfo("Failed to load header");\n success = false;\n }\n }\n else {\n LogInfo("Failed to load date count");\n success = false;\n }\n \n FileClose(file);\n }\n else {\n LogInfo("Failed to open file {}", filename);\n success = false;\n }\n return success;\n}<\/pre><\/div>\n\n\n\nI really don’t like this.\nThe successful control flow keeps getting indented more and more.\nThis is a really small example and it’s already further in than I’d like.\nIt’s hard to match success \/ fail pairs so you could end up with the wrong message.\nYou have to try and fit the whole thing in your head at once.\nI think it makes the code hard to understand.<\/p>\n\n\n\n
Logging error messages is both good and bad.\nIf you expect the function to succeed then in will help with debugging.\nIf you expect the function might fail,\nfor example if you’re trying to parse random files,\nthen it’s going to produce a lot of noise.\nI’m normally going to try and include it because sometimes that’s what you want.\nThis isn’t meant to be about exploring the easiest case.<\/p>\n\n\n\n
Return early<\/h2>\n\n\n\n
We can use the same sort of functions but change the order.<\/p>\n\n\n\n
bool ReadDates(const std::string& filename, std::vector<Date>& dates) {\n auto* file = FileOpen(filename, "r");\n if (file == nullptr) {\n LogInfo("Failed to open file {}", filename);\n return false;\n }\n \n std::string headerLine;\n if (!FileGetLine(file, headerLine) || headerLine != "Date list") {\n FileClose(file);\n LogInfo("Failed to load header");\n return false;\n }\n \n std::string countLine;\n uint32_t count;\n if (!FileGetLine(file, countLine) || !ParseUint32(countLine, count)) {\n FileClose(file);\n LogInfo("Failed to load date count");\n return false;\n }\n \n for (uint32_t i = 0; i < count; i++) {\n std::string dateLine;\n Date date;\n if (!FileGetLine(file, dateLine) || !ParseDate(dateLine, date)) {\n FileClose(file);\n LogInfo("Failed to load date line {}", i);\n return false;\n }\n dates.push_back(date);\n }\n\n FileClose(file);\n return true;\n}<\/pre><\/div>\n\n\n\nTo me this is much easier to read.\nAt the moment this is my standard coding style.\nIt does something and, if it fails, tidies up and returns immediately.\nOnce you’ve dealt with the error case you can assume it’s just going to work afterwards.\nThere is less to hold in your head at any one time.\nYou do have to watch out for the
return<\/code> keyword.\nHowever, the format normally makes them easy to spot.<\/p>\n\n\n\nHaving to repeat
FileClose<\/code> in several places is annoying.\nI can easily imagine situations where memory allocations early on would also have to be deleted\nin each failure case.\nAgain, much easier to do withstd::stream<\/code> andstd::unique_ptr<\/code>.<\/p>\n\n\n\nTry-catch<\/h2>\n\n\n\n
Exception handling use to be the big new thing.\nI hear less about it nowadays and don’t use it often.<\/p>\n\n\n\n
std::vector<Date> ReadDates(const std::string& filename) {\n FILE* file = nullptr;\n\n try {\n file = FileOpen(filename, "r");\n \n std::ignore = FileGetLine(file);\n \n uint32_t count = ParseUint32(FileGetLine(file));\n \n std::vector<Date> dates;\n for (uint32_t i = 0; i < count; i++) {\n dates.push_back(ParseDate(FileGetLine(file)));\n }\n \n FileClose(file);\n return dates;\n }\n catch (const std::runtime_error& exception) {\n if (file != nullptr) {\n FileClose(file);\n }\n throw;\n }\n}<\/pre><\/div>\n\n\n\nIt’s certainly much clearer than the previous two examples,\nalmost as simple just assuming it’s going to work.\nIf we assume that the file processing and parsing functions can throw useful
std::runtime_error<\/code>\nthen it will also provide debug information.\nHowever, requiringFileClose<\/code> has produced some awkwardness.\nIt would be a bit easier if afinally<\/code> keyword was available.<\/p>\n\n\n\nI think it’s apparent clearness is one of the reasons we hear less about it now.\nIt’s easy to program without thinking too much about it.\nAlmost every one of those lines could throw an exception.\nThat’s a lot of invisible control flow.\nI know that there are edge cases in C++ which it can end up leaking memory if you’re not careful.\nOther languages might have garbage collection but can have other resource problems.<\/p>\n\n\n\n
Short-circuit logic<\/h2>\n\n\n\n
I have often used a variant with function success \/ fail that relies on the short-circuit behaviour of
&&<\/code>.<\/p>\n\n\n\nbool ReadDates(const std::string& filename, std::vector<Date>& dates) {\n bool success = true;\n \n auto* file = FileOpen(filename, "r");\n success = success && (file != nullptr);\n \n std::string headerLine;\n success = success && FileGetLine(file, headerLine);\n success = success && headerLine == "Date list";\n \n std::string countLine;\n success = success && FileGetLine(file, countLine);\n uint32_t count;\n success = success && ParseUint32(countLine, count);\n \n for (uint32_t i = 0; success && i < count; i++) {\n std::string dateLine;\n success = success && FileGetLine(file, dateLine);\n Date date;\n success = success && ParseDate(dateLine, date);\n if (success) {\n dates.push_back(date);\n }\n }\n \n if (file != nullptr) {\n FileClose(file);\n }\n return success;\n}<\/pre><\/div>\n\n\n\nIf
success<\/code> remainstrue<\/code> then the functions will be executed.\nIf it becomesfalse<\/code> then all remaining functions will be skipped.\nUnfortunately there’s no allowance to generate error messages here.\nIf you want to know more you’ll have to add logging or step through it.<\/p>\n\n\n\nOptional values<\/h2>\n\n\n\n
Using an
std::optional<\/code><\/a>\nwe can represent a success with it’s value or a fail together.\nIt provides anand_then<\/code><\/a>\nmethod which calls a given function if it’s valid or returns another optional value if not.<\/p>\n\n\n\nstd::optional<std::vector<Date>> ReadDates(const std::string& filename) {\n auto file = FileOpen(filename, "r");\n if (!file.has_value()) {\n LogInfo("Failed to open file {}", filename);\n return nullopt;\n }\n \n const auto headerLine = file.and_then(FileGetLine);\n if (!headerLine.has_value() || headerLine != "Date list") {\n FileClose(file.value());\n LogInfo("Failed to load header");\n return nullopt;\n }\n \n const auto count = file.and_then(FileGetLine).and_then(ParaseUint32);\n if (!count.has_value()) {\n FileClose(file.value());\n LogInfo("Failed to load date count");\n return nullopt;\n }\n \n std::vector<Date> dates;\n for (uint32_t i = 0; i < count; i++) {\n const auto date = file.and_then(FileGetLine).and_then(ParseDate);\n if (!date.has_value()) {\n FileClose(file.value());\n LogInfo("Failed to load date line {}", i);\n return nullopt;\n }\n dates.push_back(date);\n }\n\n FileClose(file.value());\n return dates;\n}<\/pre><\/div>\n\n\n\nI’ve not used
and_then<\/code> before. It ends up being very similar to the “return early” version before. Rather than a success and values we combine the two. However the if-expression has to be a separate line so we don’t save any space. I’m using thehas_value()<\/code> andvalue()<\/code> methods for the optional values. It could be written more compactly using automatic convertion<\/a> and dereferencing<\/a>.<\/p>\n\n\n\nMaybe it could be better if we were willing to give up on error messages?<\/p>\n\n\n\n
Optional<std::vector<Date>> ReadDates(const std::string& filename) {\n auto file = FileOpen(filename, "r");\n \n const auto header = file.AndThen(FileGetLine).AndThen(ParseString, "Date list");\n \n const auto count = file.And(header).AndThen(FileGetLine).AndThen(ParaseUint32);\n \n auto dates = MakeOptional<std::vector<Date>>();\n for (const uint32_t i : MakeRange(count.or_else(0))) {\n dates = file.AndThen(FileGetLine).AndThen(ParseDate).AndThen(AppendValue, dates);\n }\n\n file.AndThen(FileClose);\n return dates;\n}<\/pre><\/div>\n\n\n\nI to switch away from
std::optional<\/code> to a customOptional<\/code> class because\nI wanted more fromand_then<\/code><\/a>.\nIt just takes a function but I want to give it a function and some additional arguments.\nI also added anAnd<\/code> method so thatcount<\/code> can be conditional on bothfile<\/code> andheader<\/code>.<\/p>\n\n\n\nThis has the same number of lines as “no error checking”.\nI’m impressed but also unsure about it.\nThis is definitely feels more complicated.\nExecution flows from top to bottom and all the if-statements have been hidden away inside
AndThen<\/code>.\nAs each value isOptional<\/code> you are forced to deal with errors,\nyou can’t just try to pull data from the file if it hasn’t opened properly.\nI think the biggest potential problem is failing to cascade the success status through properly.\nHere it would have been easy to code it so that a bad header didn’t matter.\nIt has to be deliberately included usingfile.And(header)<\/code> and that could be missed.<\/p>\n\n\n\nResult values<\/h2>\n\n\n\n
Similarly to
Optional<\/code> you can create aResult<\/code> type that either has a value or error details.<\/p>\n\n\n\nResult<std::vector<Date>> ReadDates(const std::string& filename) {\n auto file = FileOpen(filename, "r");\n if (file.IsError()) {\n return file.AddError("Failed to open file {}", filename);\n }\n \n const auto header = file.AndThen(FileGetLine).AndThen(ParseString, "Date list");\n if (header.IsError()) {\n FileClose(file.Value());\n return header.AddError("Failed to load header");\n }\n \n const auto count = file.AndThen(FileGetLine).AndThen(ParaseUint32);\n if (count.IsError()) {\n FileClose(file.Value());\n return count.AddError("Failed to load date count");\n }\n \n std::vector<Date> dates;\n for (uint32_t i = 0; i < count; i++) {\n const auto date = file.AndThen(FileGetLine).AndThen(ParseDate);\n if (date.IsError()) {\n FileClose(file.Value());\n return date.AddError("Failed to load date line {}", i);\n }\n dates.push_back(date);\n }\n\n FileClose(file.Value());\n return dates;\n}<\/pre><\/div>\n\n\n\nThis manages to have a more compact yet potentially richer set of error messages.\nThe error details generate by, say,
ParseUint32<\/code> could be preserved and amended by this functions error message.<\/p>\n\n\n\nCan this be re-written in a similar compact form as
Optional<\/code>?<\/p>\n\n\n\nOptional<std::vector<Date>> ReadDates(const std::string& filename) {\n auto file = FileOpen(filename, "r").\n IfErrorAdd("Failed to open file {}", filename);\n \n const auto header = file.AndThen(FileGetLine).AndThen(ParseString, "Date list").\n IfErrorAdd("Failed to load header");\n \n const auto count = file.And(header).AndThen(FileGetLine).AndThen(ParaseUint32).\n IfErrorAdd("Failed to load date count");\n \n auto dates = MakeOptional<std::vector<Date>>();\n for (const uint32_t i : MakeRange(count.or_else(0))) {\n dates = file.AndThen(FileGetLine).AndThen(ParseDate).AndThen(AppendValue, dates).\n IfErrorAdd("Failed to load date line {}", i);\n }\n\n file.AndThen(FileClose);\n return dates;\n}<\/pre><\/div>\n\n\n\nSo yes it can but this might be too far for me.\n
IfErrorAdd<\/code> lets non-error values through without change but amends error messages with more information.\nHowever it feels like the error messages are getting in my way of understanding the code.\nFor now I prefer the less compact form.<\/p>\n\n\n\nOn balance<\/h2>\n\n\n\n
I think
std::optional<\/code>,Optional<\/code> andResult<\/code> all have potential.\nI need a bit more practice with them.\nThe early return technique still has a lot to recommend it, simple to do and understand.<\/p>\n\n\n\nThe biggest frustration with all this code was
FileClose<\/code>. If you’re dealing with code that can have a number of error states minimise the amount of extra work required. Have objects that manage their own state or use statements that can tidy up for you.<\/p>\n\n\n\nThis can be a particular problem if different libraries want different<\/em> error handling techniques. Some might return raw values, some optional ones, some results and other use exception handling. That would be a mess. If a library doesn’t provide a compatible system it could be worth wrapping it up. A thin layer around the library to translate into your preferred error handling technique. Here I could have written a templated
Defer<\/code><\/a> class that can take a lambda and run it when the object was destroyed. That way I could have setup theFileClose<\/code> once and then forgotten about it. Much better.<\/p>\n\n\n\nP.S.<\/h2>\n\n\n\n
Did anyone spot the problem with these examples? I thought of it after the post had been scheduled but before it went live. None of them check that the file is actually finished before closing. According to the format there is a fixed number of dates and that’s it<\/em>, extra dates are an error. While I could go back and fix it without anyone knowing there’s also a lesson here. I go on about it enough, we all make mistakes<\/a>. If these were going in to a code base then they should have had unit tests written and, ideally, a code reviews as well. Here all the examples with error checking are valid but need an extra check which will be, say, 5 lines in the worst case and just 1 in the best case.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve used a few different error handling techniques since university. Over the last few years a couple of other options have appeared. Lets take a simple problem and see how it works with all of them. A simple problem Let’s say we want to read a text file containing a list of dates and return […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[1],"tags":[26],"class_list":["post-362","post","type-post","status-publish","format-standard","hentry","category-general","tag-languages"],"_links":{"self":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/362","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/comments?post=362"}],"version-history":[{"count":6,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/362\/revisions"}],"predecessor-version":[{"id":379,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/362\/revisions\/379"}],"wp:attachment":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/media?parent=362"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/categories?post=362"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/tags?post=362"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}