[erlang-questions] Re: Defensive Programming

[Henning Diedrich]

Thanks for the discussion Mazen! I like the motto of your blog, by the 
way. Exactly.

Since I am writing functions for somebody else to use, it's different, 
even in two steps.

First, I want to help the user if he makes wrong assumptions (yes, we 
had that before and yes I am maintaining I can pre-guess wrong 
assumptions) or mistakes. Then, I want to shield him from my own errors, 
too. (<censored thoughts>).

I'll keep an eye on how this only makes things complicated.

Thanks for your thoughts,
Henning

Robert Virding 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
>>
>>
>>     
>
>