After the theory, a quick review of common runtime error handling techniques.\nMost ecosystems focus on one, but knowing the others might come in handy in some situations.
\n--- excerpt ---
\nIn previous post, we explored levels of abstractions and the flow\nof errors through interfaces. We did not, however, examine the actual tools used to implement\nthem.
\nIn this post, we will review the main error handling paradigms.
\nThe oldest way to report errors: return a value that tells whether an error occured.
\nvoid consumer()\n{\n if (provider() != Code::Ok) {\n // handle error\n }\n // continue\n}[[nodiscard]] Code provider()\n{\n if (failure) {\n return Code::Failure;\n }\n return Code::Ok;\n}Easy to implement, easy to understand, and very portable. This is common in C-style and\ncross-language APIs.
\nIt is fully manual though, which implies significant drawbacks:
\nIn most languages, it is buggy by default: the consumer() is expected to check for error\ncodes, but if it forgets to do it, the error is silently discarded.
This specific example code uses a C++17 feature, the\n[[nodiscard]]\nattribute, to ask the compiler to verify that the consumer uses the error code,\nalleviating that risk. This feature does not exist in most languages, though.
Error forwarding adds a lot of boilerplate, as every single function along the call stack\nmust implement it manually.
\nAnd again, if a single function misses it, it is silently discarded.
\nSomewhat similar to error codes. The idea is to package in one type both information about\nsuccess or failure and the actual result.
\nvoid consumer()\n{\n auto handle = provider();\n if (handle == InvalidHandle) {\n // handle error\n }\n // use handle\n}Handle provider()\n{\n if (failure) {\n return InvalidHandle;\n }\n // continue\n return actualHandle;\n}Many variants exist, such as:
\nNULL pointers in C.open().INVALID_HANDLE_VALUE in Win32 APIs.The main point is to allow using the same approach as error codes, without having to\nuse a separate parameter.\nIt only works if the type inherently has some unused values that can be used to signify the\nlack of a useful value. That special value is called a sentinel.
\nThe method has the same pros and cons as error codes.
\nError handling as part of language control flow.
\nvoid consumer()\n{\n try {\n provider();\n } catch (const Error & err) {\n // handle error\n }\n // continue\n}void provider()\n{\n if (failure) {\n throw Error(\"blah\");\n }\n // continue\n}The main advantages of exceptions are that:
\nThis typically comes at the price of much more complexity:
\nAn error handling method is defined upfront, and error conditions cause it to be called.\nThis is used either:
\nAs it is somewhat unusual, we will not cover it.
\nSome languages and platforms favor one mechanism over others. For instance:
\nGiving context with an error tends to be difficult with error codes and sentinel values.\nIn the worst case, only one sentinel value exists (eg a NULL pointer in C) so the only\nuseful information we can send is “this failed”.
Though there are techniques to provide more information, it is usually impractical,\ninvolving saving the error context in some global state area, possibly with thread-safety\nimplications.
\nOne way to overcome the limitations of error codes comes from functional programming.
\nThe core idea is to create a type that is the sum of possible outputs and error conditions.\nThat is, after constructing such a type, a variable of that type might take either of any\npossible output value or any possible error condition.
\ntype Error = Int\ntype Value = String\ntype Result = Either Error Value\n\n-- A function that returns a value\nokFunc :: Result\nokFunc = Right \"Hello\"\n\n-- A function that fails\nfailFunc :: Result\nfailFunc = Left 42\n\n-- Consumer that uses the result\nformat :: Result -> String\nformat (Left error) = \"Error \" ++ show error\nformat (Right value) = value\n\n-- Demo\nmain = do\n putStrLn(format(okFunc))\n putStrLn(format(failFunc))Here the Result type is always either an error code or a string value.
This approach has many advantages:
\nResult carries error information with it.Result holds an error will be detected.Monadic types deserve a full article some day. They are not reserved to Haskell. For\ninstance, C++17 std::variant\nis similar to Haskell's Either that we used in the example above.
Writing this I realised that the topic is much deeper than one blog article can cover.\nEach paragraph would deserve its own post. But it was important to bring closure to\nthat short series, and maybe we will explore those in more depth later.
","fields":{"isPage":false,"slug":"/2019/error-handling-techniques"},"frontmatter":{"title":"Error Handling part 3: Techniques","classname":null,"date":"2021-04-03T00:00:00.000Z","formattedDate":"April 03, 2021","isoDate":"2021-04-03T00:00:00+00:00"},"headings":[{"value":"Error handling techniques","depth":1},{"value":"Error codes","depth":2},{"value":"Sentinel values","depth":2},{"value":"Exceptions","depth":2},{"value":"Callbacks","depth":2},{"value":"Some design considerations","depth":1},{"value":"Ecosystem practices","depth":2},{"value":"Error context","depth":2},{"value":"A word on monadic types","depth":2},{"value":"Conclusion","depth":1}],"image":null,"series":{"name":"software","fullName":"software engineering","fields":{"slug":"/software"}},"tags":[{"name":"code","slug":"/tag/code"}]}},"pageContext":{"series":"software","slug":"/2019/error-handling-techniques","previous":{"fields":{"slug":"/2019/zero-cost-unique_ptr"},"frontmatter":{"title":"Zero-cost unique_ptr deleters","series":"software"},"tags":[{"name":"code","slug":"/tag/code"},{"name":"c++","slug":"/tag/c"}]},"next":null,"seriesPrevious":{"fields":{"slug":"/2019/zero-cost-unique_ptr"},"frontmatter":{"title":"Zero-cost unique_ptr deleters","series":"software"},"tags":[{"name":"code","slug":"/tag/code"},{"name":"c++","slug":"/tag/c"}]},"seriesNext":null}}, "staticQueryHashes": ["1733002695","4006707078"]}