Defensive Programming

[Steve Davis]

Another thought that may be useful...

I've found that a _really_ good way of working out how to organize a
library api is to code two or three (reasonably real) apps against it.
When I do it that way, I find the worst holes in the api pretty
quickly, and often find that my initial guesses were not the most
important concerns at all.

regs,
/s

(btw very interesting blog post mazen, i hadn't seen that before)

On May 17, 3:53 pm, Henning Diedrich <hd2...@REDACTED> wrote:
> 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.har...@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.
> >>>> Seehttp://www.erlang.org/faq.html
> >>>> To unsubscribe; mailto:erlang-questions-unsubscr...@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.
> >> Seehttp://www.erlang.org/faq.html
> >> To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED
>
> --
> 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.