33 ms·

The "building block" APIs that Mirage use tend to be exception free, for example: https://github.com/mirage/mirage/blob/master/types/V1.mli#L235 https://github

by avsm 12y ago

The "building block" APIs that Mirage use tend to be exception free, for example: https://github.com/mirage/mirage/blob/master/types/V1.mli#L235 https://github.com/mirage/mirage/blob/master/types/V1.mli#L2... type error = [ | `Unknown of string (** an undiagnosed error *) | `Unimplemented (** operation not yet implemented in the code *) | `Is_read_only (** you cannot write to a read/only instance *) | `Disconnected (** the device has been previously disconnected *) ] val read: t -> int64 -> page_aligned_buffer list -> [ `Error of error | `Ok of unit ] io This lets the larger scale module assembly fit together with explicit checking that each device driver connected and initialised ok, and is the equivalent of basic checked exceptions. Completely checked exceptions are something of a pain to work with...

mercurial 12y ago
How exception-free are they, really? I find in practice that "exception-free" OCaml code relies largely on eyeballing + trusting underlying libraries, which isn't too reassuring. It's OK, but it's a lot like the old "programmers with enough discipline can use footguns safely" argument.
- avsm 12y ago
  The thing to remember with exceptions is that they're for exceptional situations. We check explicitly in the return value for "common" errors such as a read failure, and higher level control flow catches exceptions that bubble up and log them and/or kill that particular thread. This works pretty well in practise, and is quite similar to Erlang's monitor model. It's verbose and undesirable to handle _all_ exceptional cases in a distributed system explicitly via checked exceptions, and using monitors to catch exceptions that we're not expecting and do a process kill/log/restart is a good model in my mind. OCaml gives the language flexibility to migrate to this as well, which is nice (since, as you note, we'll never get all the third-party code we depend on to be exception-free, and nor do I think that is a desirable goal). Core and Async from Jane Street also exhibit this split: Core tends to use On_error to explicitly handle errors, and Async (being used for distributed programming) instead adopts a "raise-exception-and-catch-it-in-a-monitor" model. Theres more on that in the Async chapter in RWO: https://realworldocaml.org/v1/en/html/concurrent-programming-with-async.html https://realworldocaml.org/v1/en/html/concurrent-programming...
  - mercurial 12y ago
    This sounds reasonable. Thank you for the overview.

by avsm 12y ago

mercurial 12y ago

How exception-free are they, really? I find in practice that "exception-free" OCaml code relies largely on eyeballing + trusting underlying libraries, which isn't too reassuring. It's OK, but it's a lot like the old "programmers with enough discipline can use footguns safely" argument.

avsm 12y ago
The thing to remember with exceptions is that they're for exceptional situations. We check explicitly in the return value for "common" errors such as a read failure, and higher level control flow catches exceptions that bubble up and log them and/or kill that particular thread. This works pretty well in practise, and is quite similar to Erlang's monitor model. It's verbose and undesirable to handle _all_ exceptional cases in a distributed system explicitly via checked exceptions, and using monitors to catch exceptions that we're not expecting and do a process kill/log/restart is a good model in my mind. OCaml gives the language flexibility to migrate to this as well, which is nice (since, as you note, we'll never get all the third-party code we depend on to be exception-free, and nor do I think that is a desirable goal). Core and Async from Jane Street also exhibit this split: Core tends to use On_error to explicitly handle errors, and Async (being used for distributed programming) instead adopts a "raise-exception-and-catch-it-in-a-monitor" model. Theres more on that in the Async chapter in RWO: https://realworldocaml.org/v1/en/html/concurrent-programming-with-async.html https://realworldocaml.org/v1/en/html/concurrent-programming...
- mercurial 12y ago
  This sounds reasonable. Thank you for the overview.