BTW - I hope you are not thinking that the special syntax makes it way
to the user. It does not.
On Wed, Feb 9, 2011 at 12:26 PM, Martin Logan <martinjlo...@gmail.com> wrote:
> On Wed, Feb 9, 2011 at 8:26 AM, Eric Merritt <ericbmerr...@gmail.com> wrote:
>> I agree with you at the higher level. That exceptions need to be
>> distinguishable from non-exception errors. I am not a big fan o this
>> syntax though.
>>
>> In this we have two levels which are passing information back. The
>> pmap level and the thing that is being pmapped. Both can return
>> values. However, I don't think the pmap level should rely on the lower
>> level to map its values. So we should have this return protocol at the
>> pmap level
>>
>> {ok, _}
>> {error, ErrorType, _}
>> {exception, ExceptionType, StackInformation}
>>
>> I don't think we need a special atom for the exception at all. Its
>> location gives it the extra specialness it needs.
>
> We do need the special syntax because the current return message in
> do_f is of the form
>
> {Self::pid(), Result::term()}
>
> Where Result is user defined application level data. This means that
> anything can come back from it and we need a way to distinguish
> between application level data and lower level signals like type
> information around exceptions. This means we can do one of two things,
> enhance the protocol to look like
>
> {Self::pid(), {Type::atom(), Result::term()}}
>
> which means I need to change the protocol throughout in all cases in
> the current code. The other thing I can do is similar to what is done
> in gen_server.erl with the cast function in order to distinguish casts
> from those messages that come in out of band and should be handled by
> handle_info. Either approach is valid and has its minor plusses and
> minuses.
>
> As for the rest of your message, call me, I am not sure what you are
> trying to say honestly.
>
>
> Cheers,
> Martin
>
>
>>
>> Now realize that this is at the pmap level. If the lower level returns
>> on error, but pmap is happy could could end up with something like
>>
>> {ok, {error, _}}
>>
>> where error is just the return value from the pmapped function.
>>
>> This is different then lists:map because lists:map run in the same
>> process space as the caller and in serial. An exception lists:map
>> behaves as expected, that is it stops all processes and does a non
>> local exit. There for lists:map can just directly return the value
>> from the called function. Our pmap can not, for the reasons described
>> here.
>>
>> I hope this makes some sense.
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 8, 2011 at 9:12 PM, Martin Logan <martinjlo...@gmail.com> wrote:
>>> Guys, pmap needs to pass through exceptions. The implementation will
>>> be fairly straightforward, anyone against this?
>>>
>>> In the do_f function we have the line. I would change this line to
>>> something like
>>>
>>>
>>> Parent ! {self(), {error, ErrType, Error}}
>>>
>>>
>>> Parent ! {self(), {'$exception$', ErrType, Error}}
>>>
>>> This would be to sufficiently distinguish an exception from a passed
>>> back error. Right now we autoconvert exceptions into errors which does
>>> not look quite correct to me. There may be caveats to passing back the
>>> exception though and that is what I am asking you to think on. Anyhow,
>>> If this response above comes back into
>>>
>>> wait(Parent, Child, Timeout) ->
>>> receive
>>> {Child, Ret} ->
>>> Parent ! {self(), Ret}
>>>
>>> which would then be recognized there and passed back to Parent. When
>>> Parent receives an exception message it would rethrow it. Anyone
>>> wishing to collect all responses would need to catch exceptions at an
>>> application level. Exceptions would serve to short circuit the
>>> execution of any map functions in this way.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>>
>>> --
>>> Martin Logan
>>> Erlang & OTP in Action (Manning) http://manning.com/logan
>>> http://twitter.com/martinjlogan
>>> http://erlware.org
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "erlware-dev" group.
>>> To post to this group, send email to erlware-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> erlware-dev+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/erlware-dev?hl=en.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "erlware-dev" group.
>> To post to this group, send email to erlware-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> erlware-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/erlware-dev?hl=en.
>>
>>
>
>
>
> --
> Martin Logan
> Erlang & OTP in Action (Manning) http://manning.com/logan
> http://twitter.com/martinjlogan
> http://erlware.org
>
--
Martin Logan
Erlang & OTP in Action (Manning) http://manning.com/logan
http://twitter.com/martinjlogan
http://erlware.org
--
You received this message because you are subscribed to the Google Groups
"erlware-dev" group.
To post to this group, send email to erlware-dev@googlegroups.com.
To unsubscribe from this group, send email to
erlware-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/erlware-dev?hl=en.
