Skip to content

error handling #698

@hannesm

Description

@hannesm

as post-remarked on #690

The downside of this is that, as @talex5 remarked in mirage/mirage-console#50 (comment), the errors are now closed.

Especially for FLOW this is a bit sad, since TLS has two kinds of failures: recoverable (such as please reconfigure your required TLS version, or add some ciphersuite the other host understands) and irrecoverable (no shared implemented ciphersuite). When writing client code, I might want to handle the first by reconfiguring the stack and re-try to establish a connection, whereas the second is a hard failure.

Now, FLOW dictates which errors may happen: `Msg of string. This needs some more consideration and a followup PR before 3.0 IMHO (I wouldn't count on myself having the time to work on that, unfortunately).

Having said this, I'd guess it depends very much on the specific device where we need flexible (user-extensible) errors and where not. My assumption is that there is no need for NETIF or CONSOLE to be flexible (apart from if we want to have uniformity across everything), whereas there are incentives for FLOW being flexible.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions