Path: utzoo!attcan!uunet!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.internals
Subject: Re: Trojan Horses
Message-ID: <1893@necisa.ho.necisa.oz>
Date: 25 Oct 90 00:17:11 GMT
References: <1990Oct18.121818.9956@athena.mit.edu> <19547:Oct1818:25:2690@kramden.acf.nyu.edu> <1885@necisa.ho.necisa.oz> <5238:Oct2322:14:3690@kramden.acf.nyu.edu>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 25

In article <5238:Oct2322:14:3690@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>And if something is not documented as returning error X, and there's no
>logical reason to expect it to, and there's no good way to handle the
>error if it does come up?
>

Dan, you twist and turn -- like a twisty turny thing.

A decent interface returns ok or error.  Now there may be multiple error
classes, but all you want to distinguish is success or failure.  Failure
is usually disaster, but in some cases you can act on the error type and
try to recover.

What are you trying to say?  A new type of error has occured and because
you aren't prepared for it you say ``there's no good way to handle [it]''.
Are you saying that you treat it as success or do you just ignore it?

Surely you mean that if you don't know how to handle a specific recovery
(for some unspecified error type) it's still treated as failure?


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''