From: "Yaron Minsky" <yminsky@gmail.com>
To: "David Teller" <David.Teller@univ-orleans.fr>
Cc: OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2
Date: Mon, 11 Feb 2008 07:12:25 -0500 [thread overview]
Message-ID: <891bd3390802110412p4de4cba0me596640e55c6b994@mail.gmail.com> (raw)
In-Reply-To: <1202719508.6348.42.camel@Blefuscu>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
Something about this whole error-handling proposal confuses me. Here's my
concern: I can see 3 approaches, all having to do with what goes in the 'b
slot in the ('a,'b) status type:
1. Use different, wholly incompatible types in 'b. This allows you to
put useful information into the signature of each error-producing function,
but basically requires individual handling of each error. No monadic magic
and no conversion to exceptions is possible, and each error must be handled
individually. It's more explicit and more verbose.
2. Use the same type in 'b everywhere. There's no extra explicitness
here, and I don't actually see any advantage over just using exceptions.
3. Use different but compatible types, e.g., polymorphic variants.
Then you get both explicitness and the chance to use monadic or other tricks
to join together the errors at the type level. That has some clear
advantages (the type system can infer for you the ser of all possible error
messages), but we've found it leads to some sticky type error messages in
some cases.
So, I understand why someone would try (1) or (3), but (2) seems utterly
pointless to me. The proposal seems to be aiming at (1), but then there's
all this talk of monads which doesn't seem to fit (1).
Am I missing something?
y
[-- Attachment #2: Type: text/html, Size: 1417 bytes --]
next prev parent reply other threads:[~2008-02-11 12:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 15:01 David Teller
2008-02-07 15:09 ` [Caml-list] " Vincent Hanquez
2008-02-07 16:40 ` David Teller
2008-02-07 15:17 ` Jacques Garrigue
2008-02-07 15:22 ` Jon Harrop
2008-02-08 9:54 ` Vincent Hanquez
2008-02-07 15:52 ` David Teller
2008-02-07 16:06 ` Olivier Andrieu
2008-02-07 16:23 ` David Teller
2008-02-08 9:53 ` Vincent Hanquez
2008-02-08 10:52 ` rlehy
2008-02-08 11:56 ` Vincent Hanquez
2008-02-08 12:40 ` Bünzli Daniel
2008-02-08 15:39 ` David Teller
2008-02-08 17:06 ` Eric Cooper
2008-02-08 20:02 ` David Teller
2008-02-08 19:29 ` Bünzli Daniel
2008-02-08 21:13 ` David Teller
2008-02-10 12:35 ` Vincent Hanquez
2008-02-08 19:07 ` Jon Harrop
2008-02-10 11:58 ` Vincent Hanquez
2008-02-10 16:51 ` Matthew William Cox
2008-02-07 15:33 ` Jon Harrop
2008-02-07 16:25 ` David Teller
2008-02-07 23:10 ` David Teller
2008-02-10 18:47 ` Yaron Minsky
2008-02-10 22:05 ` David Teller
2008-02-11 2:16 ` Yaron Minsky
2008-02-11 8:45 ` David Teller
2008-02-11 12:12 ` Yaron Minsky [this message]
2008-02-11 12:53 ` David Teller
2008-02-11 23:09 ` Yaron Minsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=891bd3390802110412p4de4cba0me596640e55c6b994@mail.gmail.com \
--to=yminsky@gmail.com \
--cc=David.Teller@univ-orleans.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox