Module errors 

Error handling is an important part of the mem-isolate crate. If something went wrong, we want to give the caller as much context as possible about how that error affected their callable, so they are well-equipped to know what to do about it.

The primary error type is MemIsolateError, which is returned by crate::execute_in_isolated_process.

Philosophically, error handling in mem-isolate is organized into three levels of error wrapping:

1. The first level describes the effect of the error on the callable (e.g. did your callable function execute or not)
2. The second level describes what mem-isolate operation caused the error (e.g. did serialization fail)
3. The third level is the underlying OS error if it is available (e.g. an io::Error)

For most applications, you’ll care only about the first level. For an example of common error handling dealing only with first level errors, see examples/error-handling-basic.rs.

Levels two and three are useful if you want to know more about what exactly went wrong and expose internals about how mem-isolate works.

Note: These errors all describe things that went wrong with a mem-isolate operation. They have nothing to do with the callable you passed to crate::execute_in_isolated_process, which can define its own errors and maybe values by returning a Result or Option type.

Enums

CallableDidNotExecuteError

An error indicating something went wrong before the user-supplied callable was executed

CallableExecutedError

An error indicating something went wrong after the user-supplied callable was executed

CallableStatusUnknownError

An error indicating that something went wrong in a way where it is difficult or impossible to determine whether the user-supplied callable was executed ¯\_(ツ)_/¯

MemIsolateError

MemIsolateError is the primary error type returned by the crate. The goal is to give the caller context about what happened to their callable if something went wrong.