1079702 - B2G RIL: reconsider the use of some dictionaries in MozMobileConnection APIs

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Jessica Jong [:jessica] (inactive)]

This is a follow-up to Bug 1047196 comment 68.

[quote]
<If different methods take a bit different kind of dictionary with different set of require properties, perhaps 
better to add new dictionaries and use required keyword. (Support for 'required' was added very recently.)>

We should reconsider the use and structure of MozCallBarringOptions and MozCallForwardingOptions dictionaries in MozMobileConnection.webidl.

Comment 1

[Jessica Jong [:jessica] (inactive)]

One more thing to note, from Bug 1047196 comment 74:

[quote]
<(Usually invalid params cause exception, not async error, but since async error is already thrown, no need to change that in this bug.)>

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Apparently WebIDL spec has a very odd special case for Promise (and DOMRequest is a Promise like thing), where such errors are async after all.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Olli Pettay [:smaug] from comment #2)
> Apparently WebIDL spec has a very odd special case for Promise (and
> DOMRequest is a Promise like thing), where such errors are async after all.

yup, I learned that from http://www.w3.org/2001/tag/doc/promises-guide#api-design-guidance


Per the spec, the section of 
"Good cases for rejections include:
... ...
Any situation where something is internally broken while attempting an asynchronous operation: for example if the user passes in invalid data, or the environment is in an invalid state for this operation."

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #1)
> One more thing to note, from Bug 1047196 comment 74:
> 
> [quote]
> <(Usually invalid params cause exception, not async error, but since async
> error is already thrown, no need to change that in this bug.)>

Hi Olli,

I thought about this comment again; however I am still wondering if throwing an exception makes more sense. Doesn't rejecting a promise make the API consumer's life easier even invalid params could simply be checked synchronously? Because in this way, they could simply have a single way of error handling in all circumstances, instead of having duplicate error handling logic, e.g. catch (e) {}  and .catch( e => {}). May I ask for more explanations? Thank you.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

It is the inconsistency in the APIs which bothers me a lot.
Why returning a Promise makes plain normal parameter type validation behave totally different to
non-Promise cases. And an invalid param is most likely a major error in program logic, so it should
be reported as soon as possible, not asynchronously using optional Promise's callback.
(This craziness is a reason why I personally prefer to not propose use of Promises in APIs - 
 but I also am not really against them if other people want to use them)

One shouldn't need to use try-catch normally. The exception should be thrown in exceptional cases, and that should usually stop
executing the currently run script.

But since WebIDL specs the totally insane Promise+exception handling and it is possibly too late to change that, I guess I just need to live with that.

Comment 6

[BMO Automation]

Firefox OS is not being worked on