[erlang-questions] Best practices for handling invalid / unexpected messages

[Edmond Begumisa]

To clarify, I'm referring to a contract checker for ordinary Erlang terms  
passed within the same VM instance and not TCP/port communication as is  
currently with UBF.

- Edmond -

On Sat, 14 May 2011 22:52:12 +1000, Edmond Begumisa  
<ebegumisa@REDACTED> wrote:

> On a related note,
>
> I've now and then wondered about a UBF-style contract checker for  
> gen_server and gen_fsm messages. I realise pattern matching is kind of  
> implied contract checking (invalid messages don't get matched), but I  
> like the UBF idea of starting with a contract then coding the modules  
> from there rather than the other way around. The type-checking is also  
> very useful.
>
> Any thoughts?
>
> - Edmond -
>
> On Sat, 14 May 2011 06:20:42 +1000, Joe Armstrong <erlang@REDACTED>  
> wrote:
>
>> No easy answer:
>>
>> During development:
>>
>>     Crash loudly - print lots of information about why you crashed
>>     do init:stop() or erlang:halt() *force* the programmer to fix the  
>> code
>>
>> During production
>>
>>     Crash silently - put lots of error in the log and send rude email to
>> programmer
>>     if you can recover do so. If you cannot recover tell the user as
>> politely as possible.
>>     *never* present the user with internal error message (this is most
>> unprofessional)
>>
>> What you do with an error thus depends upon the context where it occurs  
>> -
>> basically
>> tell the programmer the truth and give them all the info needed to fix  
>> the
>> error, while
>> apologizing to the end user ... send an email to the project manager  
>> telling
>> the code
>> is broken if you want the programmer to fix it :-)
>>
>> /Joe
>>
>>
>>
>> On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek  
>> <freza@REDACTED>wrote:
>>
>>> # Ciprian Dorin Craciun 2011-05-13:
>>> >     Lately I've started programming a bit more seriously in Erlang,
>>> > and after creating a few `gen_server` or `gen_fsm` components, I've
>>> > started wondering what is the best way to handle unexpected or  
>>> invalid
>>> > requests / messages. [...]
>>> >
>>> >     I think of three possibilities:
>>> >     * reply back with an error:
>>>
>>> Yep, this is what I do:
>>>
>>>  handle_call(_, _, State) ->
>>>      {reply, {error, bad_request}, State}.
>>>
>>>  handle_info(_, State) ->
>>>      {noreply, State}.
>>>
>>> It's similar with gen_fsm & custom processes.
>>>
>>> >     Now each of these have advantages or disadvantages:
>>> >
>>> >     * the first one is "polite" to the caller, letting him retry,
>>> >       but could lead to hidden bugs if the caller doesn't check
>>> >       the return term;
>>>
>>> It also helps forward-compatibility in presence of hot code upgrades.
>>>
>>> >     Furthermore, let's say a process depends in his operation on
>>> > another process, should it link the dependency process, should it
>>> > monitor, or should it just fail on call?
>>>
>>> Depends on how tightly they're bound together. Linking them means "one
>>> can't live without the other even for a second", monitoring means "one
>>> is vaguely interested if the other is still alive" (often to clean up
>>> some mess when the other dies), fail on call means "ok, I need you to
>>> handle my request now, but generally I don't really care about you".
>>>
>>> The last option is by far the most common, the other two are employed
>>> tactically in cases where it matters.
>>>
>>> HTH,
>>>         -- Jachym
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/