RE: JSON-LD API w/DOM Futures implemented

On Thursday, April 25, 2013 5:54 PM, Dave Longley wrote:
> > I think you refer to the three that check the parameters. I believe
> that's
> > an error in your implementation. If you have a function like
> >
> >     Future expand (JsonLdInput input, optional JsonLdOptions
> options);
> >
> > and you call it without any parameters (expand()) it should throw an
> > TypeError instead of returning a Future. You have to keep in mind
> that these
> > things will most of the time be implemented in C++. You can't just
> omit a
> > parameter in that case.
> 
> The problem is that it is unclear when that error should be thrown.
> When
> using Futures, it is expected that any errors will propagate via the
> Future's rejection API -- when an attempt is made to resolve the
> Future.
> It might be incorrect to throw TypeErrors prior to trying to resolve
> the Future.
> If the behavior is as you changed, then it will cause a lot of
> headache (code duplication) for APIs that are wrapped using Futures, as
> their errors will be passed via callback (eventually to the Future's
> rejected() callback), not immediately thrown. There may be other
> headaches like mixing try/catch with rejection callbacks during
> chaining. It's unclear how a C++ implementation for this would work --
> it may always generate a Future that will be rejected in this case.

Good that you mention C++. If you define a function that has a
*non*-optional parameter and try to call it without passing any parameter in
a statically typed and compiled language your compiler will simply refuse to
compile your code. The reason is that you tried to call a non-existent
function. The compiler can't find any function with matches the signature
you used.

So this has nothing to do with error propagation or wrapping existing APIs.
It is just a result of JavaScript being so lazy (or tolerant, depending on
how you look at it). WebIDL clearly differentiates between optional and
non-optional parameters. Obviously you can't omit a non-optional parameter.

The thing where we seem to disagree is whether the function is called at all
or not. If I'm not completely misunderstanding you (and I doubt I am), you
are saying that the function will be called even if the signature used by
the caller doesn't correspond to the signature definition of the method. I'm
arguing that the function is not called at all and thus an error is raised
directly instead of being returned via the Future.



--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 27 April 2013 14:59:44 UTC