[erlang-questions] Re: Defensive Programming

[Robert Virding]

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