{"id":4515,"date":"2018-12-24T16:33:12","date_gmt":"2018-12-24T22:33:12","guid":{"rendered":"http:\/\/neosmart.net\/blog\/?p=4515"},"modified":"2018-12-24T18:00:25","modified_gmt":"2018-12-25T00:00:25","slug":"rust-ignore-result","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/rust-ignore-result\/","title":{"rendered":"ignore-result: A simple crate to make ignoring rust Results safe and easy"},"content":{"rendered":"

\"\"<\/a>Rust, both by design and by convention, has a fairly strongly defined model for strict error handling, designed to force developers to deal with errors up front rather than assume they don’t exist. If you stick to a few conventions and principles for best practice, error handling becomes fairly straight-forward (although what you ultimately do with the errors is a different question) if you are living in an all-rust world. The problems start when you step foot outside of the comfortable world of crates and Result<\/code>s, such as when dealing with FFI to interface with C libraries or using rust in an embedded context.<\/p>\n

The typical approach for dealing with errors in rust in 2018 is to have any function that can encounter a scenario wherein it is unable to return a valid value declare a return type of Result<T, E><\/code>\u00a0where T<\/code>\u00a0is the expected result type in normal cases and E<\/code>\u00a0is a type covering possible errors that can arise during execution. When calling from one such function into other functions with non-guaranteed success, the typical control flow in the event of an error is almost always “early out”:<\/p>\n

<\/p>\n

\/\/\/ A function that does something and produces no result,\r\n\/\/\/ except in case of an error, in which case it returns an\r\n\/\/\/ instance of the type `Error`\r\nfn do_something() -> Result<(), Error> {\r\n    inner_func_call();\r\n    inner_func_call_may_fail()?;\r\n    return Ok(());\r\n}\r\n<\/code><\/pre>\n
In the example above, the ?<\/code>\u00a0in inner_func_call_may_fail()?<\/code>\u00a0is shorthand for “if the result of inner_func_may_fail()<\/code>\u00a0is an error of type Error<\/code>, bubble it up to the caller immediately rather than continuing on to the next line in this function (and if it produced a result, “unwrap” the Ok(whatever)<\/code>\u00a0result to evaluate to whatever<\/code>\u00a0directly).<\/p>\n
So far, so good. I’m not going to delve into the nitty-gritty of match<\/code>\u00a0blocks, what an Error<\/code>\u00a0type declaration looks like, or what you ultimately do with the error when it can bubble up no more. But let’s look at a common practice from the C world:<\/p>\n
int destroy_resource(Foo *foo) {\r\n    if (_lucky) {\r\n        return STATUS_SUCCESS;\r\n    }\r\n    return STATUS_SOME_ERROR;\r\n}\r\n\r\nint do_something() {\r\n    Foo *foo = create_resource();\r\n    if (!foo) {\r\n        return STATUS_CREATION_FAILURE;\r\n    }\r\n    int result = use_foo(foo);\r\n    if (result != STATUS_SUCCESS) {\r\n        destroy_resource(foo);\r\n        \/\/ bubble up the original `result`\r\n        return result;\r\n    }\r\n\r\n    \/\/ do some other stuff\r\n    result = destroy_resource(foo);\r\n    if (result != STATUS_SUCCESS) {\r\n        return result;\r\n    }\r\n    return STATUS_SUCCESS;\r\n}\r\n<\/code><\/pre>\n
Pay close attention to what happens in case do_something()<\/code>\u00a0failed to execute use_foo()<\/code>\u00a0successfully: it runs a cleanup function\u00a0that may fail<\/em> but bubbles up the original error result<\/code>\u00a0rather than the error returned by destroy_resource()<\/code>\u00a0– which makes sense, since it’s the original error that started this problem in the first place. In fact, in this particular case we don’t even handle the result of destroy_resource()<\/code>\u00a0at all, mainly because there’s nothing we can do about it. It was a “best effort” attempt at freeing allocated resources – we called the function for its side effects, but we don’t\u00a0rely<\/em> on the result of the function for anything, i.e. we are not predicating future actions based on assumption that this call succeeded.<\/p>\n
In rust, in developing an abstraction for this C API (so you still need to worry about things like resource allocation and memory leaks since they haven’t yet been abstracted away), you might be tempted to write it as follows:<\/p>\n
fn do_something() -> Result<(), E> {\r\n    let foo = create_foo()?;\r\n    let result = use_foo(&foo);\r\n    if result.is_err() {\r\n        free_foo(foo)?;\r\n        return result;\r\n    }\r\n    \/\/ do other stuff\r\n    free_foo(foo)?;\r\n    return Ok(());\r\n}\r\n<\/code><\/pre>\n
Or if you’re a masochist that insists on using match<\/code> exclusively and shuns return ...;<\/code> at the end of function blocks “because clippy said so”, you might write it like this instead:<\/p>\n
fn do_something() -> Result<(), Error> {\r\n    let foo = create_foo()?;\r\n    match use_foo(&foo) {\r\n        Ok(_) => {},\r\n        Err(e) => {\r\n            free_foo(foo)?;\r\n            return Err(e);\r\n        }\r\n    }\r\n    \/\/ do other stuff\r\n    free_foo(foo)?;\r\n    Ok(())\r\n}\r\n<\/code><\/pre>\n
The point is, the error handling above in both cases is likely wrong, because the error that gets bubbled up here is the result of free_foo()<\/code>, which went wrong only after use_foo()<\/code> failed. The result<\/code>\u00a0of use_foo()<\/code>\u00a0contains the real Err(e: Error)<\/code>\u00a0we are interested in, that is what should have been bubbled up to the caller instead. If you were to instead omit the ?<\/code>\u00a0from that call to free_foo()<\/code>, the correct error (result<\/code>) would be bubbled up to the caller — but the compiler will complain about an used result:<\/p>\n
warning: unused result which must be used<\/p><\/blockquote>\n
A warning that comes from a good place, but is nonetheless complaining about a purposely ignored return value (there’s nothing we can do about it here\u00a0and<\/em> there’s a more correct Error<\/code>\u00a0to be bubbled up).<\/p>\n
Since there’s literally nothing we can do about an inability to free the Foo<\/code>\u00a0instance, if we\u00a0were<\/em> to handle the result to try and silence the warning, the code would necessarily look something like this:<\/p>\n
fn do_something() -> Result<(), Error> {\r\n    let foo = create_foo()?;\r\n    let result = use_foo(&foo);\r\n    if result.is_err() {\r\n        match free_foo(foo) {\r\n            _ => {}\r\n        };\r\n        return result;\r\n    }\r\n    \/\/ do other stuff\r\n    free_foo(foo)?;\r\n    return Ok(());\r\n}\r\n<\/code><\/pre>\n
With an empty match<\/code> block that serves no purpose but to silence the compiler (and gets optimized away into nothing). A beginner to rust might be tempted to use free_foo(foo).unwrap()<\/code>\u00a0instead to work around that warning, but that would be a\u00a0grave<\/em> mistake since the function might very well fail, we just don’t care if it does — but calling .unwrap()<\/code>\u00a0on a Result<\/code>\u00a0means incurring a panic if it indeed evaluated to an error.<\/p>\n
ignore-result<\/code>\u00a0is a very simple (no_std<\/code>) crate that extends Result<_, _><\/code>\u00a0with a .ignore() -> ()<\/code>\u00a0method that consumes a Result<T,E><\/code>\u00a0coming out of a function and always returns ()<\/code>\u00a0– regardless of what the T<\/code>\u00a0and E<\/code>\u00a0types were. This represents a deliberate handling of both the Ok<\/code>\u00a0and Err<\/code>\u00a0variants on your end (quieting the warnings), discards an error we can’t do anything about\u00a0while simultaneously blocking us from assuming success<\/em> by return ()<\/code>\u00a0regardless of what T<\/code>\u00a0was in this case. In calling .ignore()<\/code>, you are explicitly saying “I don’t care of this function succeeds or fails, but I need to call it anyway (and I’ll pray it succeeds but no sweat off my back if it doesn’t),” which is perfectly safe since you can’t violate that contract with the code\/compiler by then going ahead and using the Ok(whatever)<\/code>\u00a0variant (like a call to .unwrap()<\/code>\u00a0would return).<\/p>\n
Compare the resulting code to the variants above, and I think you’ll agree it’s simpler, shorter, more expressive, and nicer to boot:<\/p>\n
fn do_something() -> Result<(), E> {\r\n    let foo = create_foo()?;\r\n    let result = use_foo(&foo);\r\n    if result.is_err() {\r\n        free_foo(foo).ignore();\r\n        return result;\r\n    }\r\n    \/\/ do other stuff\r\n    free_foo(foo)?;\r\n    return Ok(());\r\n}\r\n<\/code><\/pre>\n
I don’t expect that typical rust developers coding within the rust ecosystem will have need of this crate, it’s expressly for use by developers interacting with non-rusty APIs. It doesn’t do anything magic or anything special, but it does make your code (and the intend behind it) much clearer and more succinct than an empty match<\/code>\u00a0block ever could. The crate is no_std<\/code>\u00a0with zero dependencies (the IgnoreResult<\/code>\u00a0trait was yanked from some embedded rust code for a rust-powered RFM69HCW library) and ideally compiles away to nothing at all.<\/p>\n
As the Ignore<\/code>\u00a0name is already in use by another (wonderful) library, this crate can be found at crates.io<\/a> under the name ignore-result<\/code>\u00a0and is released as an open source (MIT-licensed) library to our github profile<\/a>. The docs are available on docs.rs<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Rust, both by design and by convention, has a fairly strongly defined model for strict error handling, designed to force developers to deal with errors up front rather than assume they don’t exist. If you stick to a few conventions … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":505,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[989,994,52,936],"class_list":["post-4515","post","type-post","status-publish","format-standard","hentry","category-software","tag-crate","tag-ignore-result","tag-open-source","tag-rust"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4xDa-1aP","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/4515","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/users\/505"}],"replies":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/comments?post=4515"}],"version-history":[{"count":7,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/4515\/revisions"}],"predecessor-version":[{"id":4522,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/4515\/revisions\/4522"}],"wp:attachment":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/media?parent=4515"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/categories?post=4515"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/tags?post=4515"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}