"open" vs "closed" cases

Chris Pressey cpressey@REDACTED
Mon Apr 21 01:07:28 CEST 2003

On Wed, 16 Apr 2003 23:29:02 +0200
"Robert Virding" <robert.virding@REDACTED> wrote:

> Definitely the closed case. The extra cost is negligible and the
> meaning much clearer, especially if the test is not so obviously a
> "safe" boolean.
> Robert

OK, I've been looking at the way I write code, and I often use "open"
cases - partly because I communicate at the user level (or a level where
I want to assume certain defaults if input is missing or incorrect), and
partly because I'm lazy and I know it's a bad habit but I do it anyway.

As penance, I *have* been trying to write stricter interfaces & cases
where appropriate lately, for example in the new API for my webserver, I
have the following interface (roughly) for modules:

  start(conf()) -> conf()

  serve(conf()) -> {not_found, conf()} | {{serve, data()}, conf()}

In the first case, crashing if something goes wrong is good; there's
nothing sensible that can be done after a module can't be started.

In the second case, the error is not really a 'show-stopper' type error
- it's more like a condition, so I pass it back as a value.
(However, if the serve function does crash, the webserver does generate
a 501 internal server error response - which also makes sense.)

So, yes - I agree (with Robert) that errors come in a spectrum.  I also
agree (with Ulf) that it's usually best to write only for the correct
case and let everything else crash - and I hope that a future version of
Erlang will incorporate 'try', to make that option even more feasible.


More information about the erlang-questions mailing list