ok or true?

[Shawn Pearce]

Lennart ?hman <lennart.ohman@REDACTED> wrote:
> Hi, this is of course a matter of religion :-) But I have always
> preached that one should look at what the opposite return value
> will be if you have problem deciding.
> 
> So, if the opposite would be some kind of error ({error,Reason})
> then 'ok' denotes a success.

This makes a lot of sense, thanks.

> One should also use the rule of not making assumptions about what
> the return value will be used for. With this I mean that ok/error
> makes such an assumption (about what is desired and what is not). But
> true/false does not.

This I don't quite understand.  If I shouldn't make assumptions about
what the return value will be used for, why is ok/error suitable, as
it is making the assumption that most times the function will be:

	case foo() of
	ok ->  ....;
	{error, Why} -> ...
	end

Yet true/false also makes the assumption that it would be used
in a boolean context.

This is an old debate, I remember now reading a very long thread on
this.  That thread also got into the throw/catch and exit/catch,
etc.  I don't want to reopen the debate.  :-)

One can usually expect gen_tcp:send, etc. to always return ok.
If it doesn't, the caller usually winds up just exiting from their own
process, usually with a badmatch.  Yet gen_tcp:send returns ok/error.
No complaint here, just making an observation.

I'm coding with ok/error for my functions.  However they should
never fail, as the port and the process which owns the port are
generally always linked to the caller.  (The caller does not
trap_exit.)  So if something goes wrong, you'd never know.  :-)
(Actually the supervisor will notice, log the error and restart.)

-- 
Shawn.

  news: gotcha