[erlang-questions] Re: Defensive Programming
Joe Armstrong
erlang@REDACTED
Tue May 18 11:35:25 CEST 2010
Programs crash either by design (it was *supposed* to crash) or by omission
(you omitted to write code to stop it from crashing)
Imagine dividing by zero. I write:
X = A/B
When I write this line of code I think to myself - "what happens if B
is zero?" and
"If B is is zero am I happy that the default recovery mechanisms take
care of the error?"
If the answer is yes - (ie I'm happy that the default mechanisms take
care of the error)
then I just write A/B. If the answer is no, then I must write defensive code:
But writing the defensive code is *difficult*
I can't write:
X = case B of
0 -> .... do something else ...
_ -> A/B
end
This would be logical nonsense, X has no value if B is 0 (you *could*
write X = nAn (not a Number)
but then you'd have to handle it at all points where X ( a number)
was expected.
So you'd have to write
case B of
0-> do this;
_ -> do something else
end.
This would break the entire structure of your code, a simple A/B in
the middle of a sequence of statements who change the entire shape
of the code
foo() ->
...
a,
b,
X = A/B,
c,
d.
would change from a simple sequence to
foo() ->
...
a,
b,
case B of
0 ->
... something ...
_ ->
c,
d
end.
Use divide a couple of times in your code and you'd soon get an
impenetrable mess of codes.
Letting the default recovery mechanism handle the error is almost
always the right thing to do.
If it is not the right thing to do, then you can 1) improve the
default mechanism
or 2) write your own error handling code.
1) is a good - since it will probably benefit other code as well (ie
the default mechanism should be generic)
(that's why gen_* things are popular - they try to "do the right
thing" when you crash).
2) turns errors into "part of the problem" and as such they should be
specified. Once they are
specified, coded, and handled they no longer become errors they become
defined and specified behavior.
This argument is somewhat long .. the 0,5 second summary is "let it crash"
/Joe
On Mon, May 17, 2010 at 10:08 PM, Robert Virding <rvirding@REDACTED> wrote:
> I was going to say that you should handle the error where it is most
> sensible to do so but you said it better. :-)
>
> Robert
>
> 2010/5/17 Mazen Harake <mazen.harake@REDACTED>:
>> I wrote this once... see if it makes sense:
>> http://mazenharake.wordpress.com/2009/09/14/let-it-crash-the-right-way/
>>
>> /Mazen
>>
>>
>> On 17/05/2010 02:12, Henning Diedrich wrote:
>>>
>>> Thanks Steve,
>>>
>>> that question of "is it recoverable?" makes a lot of sense to clarify. I
>>> am taking note.
>>>
>>> In my case I am writing a lib function for others to use, which is exactly
>>> why I would like to give them more information on the error.
>>>
>>> Even though they might not be able to recover it, they should at least
>>> know why it didn't work, instead of just getting a bad match for "ok = "
>>>
>>> I meanwhile conclude that the trimmest variant will be to care less and
>>> demand that the user of the function test for the return value directly
>>> handed over from the gen_tcp:send() call. Making it
>>>
>>> login(Name, Password) ->
>>>
>>> ...
>>> gen_tcp:send(Socket, term_to_binary(Str)).
>>>
>>>
>>>
>>> That looks the Erlangest an hands responsibility to the person who can
>>> actually answer the 'recoverability question', the user of the lib.
>>>
>>> I realize I'd like to take away chances of frustration, puffing it up in
>>> the process.
>>>
>>> Thanks for taking a look!
>>> Henning
>>>
>>>
>>>
>>> Steve Davis wrote:
>>>>
>>>> Hi Henning,
>>>>
>>>> This isn't intended to be any kind of definite answer, and I'm
>>>> interested to see how others respond.
>>>>
>>>> In my case how I deal with this question is that I'd probably ask
>>>> myself:
>>>>
>>>> *Is this exceptional case _recoverable_,? e.g. in the case of the tcp
>>>> send, you could try to resend the data, so the first idiom may do it.
>>>>
>>>> If it's not recoverable, I'd just let it crash out. In fact I would
>>>> likely force it to crash out using the second idiom.
>>>>
>>>> If I want to get fancy with error handling, I find that try..catch at
>>>> the top level is usually enough.
>>>>
>>>> A further aside to this is that a certain Mr Armstrong once introduced
>>>> me to an interesting "transactional" idiom also, namely:
>>>>
>>>> try begin
>>>> ...
>>>> end catch
>>>> ...
>>>>
>>>> Regards,
>>>>
>>>> /s
>>>>
>>>> On May 16, 5:04 pm, Henning Diedrich <hd2...@REDACTED> wrote:
>>>>>
>>>>> Hi list,
>>>>>
>>>>> I have a question about the Erlang way.
>>>>>
>>>>> I realize I keep programming defensive using exceptions/error calls to
>>>>> *label failure* more precisely.
>>>>>
>>>>> E.g. ( - PRESUMABLY WRONG - )
>>>>>
>>>>> login(Name, Password) ->
>>>>>
>>>>> ...
>>>>> case
>>>>> gen_tcp:send(Socket, term_to_binary(Str)) of
>>>>> ok -> ok;
>>>>> _ -> erlang:error(*sending_failed, {Str }*)
>>>>> end
>>>>> ...
>>>>>
>>>>> Instead of simply
>>>>>
>>>>> login(Name, Password) ->
>>>>>
>>>>> ...
>>>>> ok = gen_tcp:send(Socket, term_to_binary(Str)),
>>>>> ...
>>>>>
>>>>> It feels wrong in Erlang and I wonder if I am missing out on something.
>>>>>
>>>>> If somebody has a pointer to read up on this, thanks in advance,
>>>>>
>>>>> Henning
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Erlang Programming" group.
>>>>> To post to this group, send email to
>>>>> erlang-programming@REDACTED
>>>>> To unsubscribe from this group, send email to
>>>>> erlang-programming+unsubscribe@REDACTED
>>>>> For more options, visit this group
>>>>> athttp://groups.google.com/group/erlang-programming?hl=en.
>>>>
>>>> ________________________________________________________________
>>>> erlang-questions (at) erlang.org mailing list.
>>>> See http://www.erlang.org/faq.html
>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------
>>
>> ---------------------------------------------------
>>
>> WE'VE CHANGED NAMES!
>>
>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG
>> SOLUTIONS LTD.
>>
>> www.erlang-solutions.com
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>
More information about the erlang-questions
mailing list