Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
To: "caml" <caml-list@inria.fr>
Subject: RE: [Caml-list] Exceptions considered harmful
Date: Tue, 29 Jun 2004 11:05:45 -0700	[thread overview]
Message-ID: <OOEALCJCKEBJBIJHCNJDEEHPHEAB.vanevery@indiegamedesign.com> (raw)

skaller wrote:
>
> Any comments on any of this appreciated.

Being worn out from a dismal weekend of sub minimum wage signature
gathering (HOW can I get pa-id for my actual computer interests?) I did
not follow your logic too closely.

It seemed to me that to partially resolve your issues, whatever is
thrown must simply carry a lot more information about context, type of
error, etc.  Many languages allow typed information to be thrown, for
instance, C++.  I'm still a noob at OCaml; I thought it could do that
sort of thing.

I say 'partially' because exception handling is always a policy
decision.  You simply cannot get away from crafting policies about what
to do when something doesn't work.

The problem is, do you have the implementation time to craft those
policies?  I usually don't.  It takes me 6 times to get any design
correct, and I do not want to spend a pile of design time on error
conditions when I know the code may very well be thrown out anyways.

If you pass the buck to the next level up, then you have a 'whiney API'.
If you're the boss of a company, do you really want tons of workers
whining about every little thing, saying "I've failed!  I don't know
what to do!  Can you handle this for me?  Pleeeze??"  No, you'd fire
'em.  They're supposed to be doing jobs; you're supposed to be
delegating jobs to them, to hide the complexity of your corporate
operations.  You want answers, not more problems.

Sadly, I think exception handling is only a valid approach to software
engineering once an API is reaching 'maturity'.  One really should just
go back into it and rigidly define what's gonna happen when all of the
well-understood design parameters are violated.  As an alternative, one
could code very cautiously, at a snail's pace.  You could ensure that
exceptions are always thrown, even if nobody knows how to use the API
yet and it's fundamentally 'in flux'.  In an industrial context on
someone else's nickel, that might be the way to go.  But I certainly
can't afford it in my own development.


Cheers,                         www.indiegamedesign.com
Bran-don Van Every              Se-attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  evil crap!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


             reply	other threads:[~2004-06-29 17:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-29 18:05 Brandon J. Van Every [this message]
     [not found] <20040628143917.GA21847@fichte.ai.univie.ac.at>
     [not found] ` <Pine.LNX.4.44.0406290056580.1229-100000@localhost>
     [not found]   ` <20040628173400.GB26193@fichte.ai.univie.ac.at>
2004-06-29  1:02     ` skaller
2004-07-04  7:30       ` Lauri Alanko
2004-07-04 20:16         ` Christophe TROESTLER
2004-07-04 20:24         ` Michael Hicks
2004-07-05  3:42           ` skaller

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=OOEALCJCKEBJBIJHCNJDEEHPHEAB.vanevery@indiegamedesign.com \
    --to=vanevery@indiegamedesign.com \
    --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