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