Don't throw E_MISSING_PARAMETER on execution

[rxaviers]

Formatters and parsers throw E_MISSING_PARAMETER when any parameter is missing. For example:

Globalize('en').currencyFormatter()
// > currency: E_MISSING_PARAMETER: Missing required parameter `currency`.

It happens that it also throws on execution, for example:

var fmt = Globalize('en').currencyFormatter('USD');
fmt();
// > value: E_MISSING_PARAMETER: Missing required parameter `value`.

This could be an undesired validation, pointed out by #306. Also, it's a behavior not observed by native JavaScript, for example:

parseFloat();
// > NaN

var fmt = new Intl.DateTimeFormat('en');
fmt.format()
// > "10/10/2015"

fmt = new Intl.NumberFormat('en')
fmt.format()
// > "NaN"

Therefore, we could preserve the parameter validations for setup phase, i.e., when formatters or parsers are generated. But, we could drop them for execution and instead use a default like shown above.

[rxaviers]

RFC: cc @jquery/globalize

[jzaefferer]

Therefore, we could preserve the parameter validations for setup phase, i.e., when formatters or parsers are generated. But, we could drop them for execution and instead use a default like shown above.

In what scenario would you pass a value in the setup phase?

[rxaviers]

A value none. I am naming setup phase the phase where formatters and parsers are generated, not executed. Therefore, parameters used in this phase are generally options that modifies the formatter (like date pattern, number fraction digits) or required arguments like currency code, relative time unit, etc. But, not the value itself that is formatted.

[sompylasar]

@rxaviers The implicit behavior provided by the JavaScript platform is more error-prone than the explicit error throwing provided currently by Globalize. Please don't encourage implicit behavior by not throwing errors on missing or invalid input data during execution. The error reporting should be consistent.

[rxaviers]

@sompylasar it's true when generating the formatters, but I've started to believe this isn't true for its execution.

Usually, when generating the formatters, any missing parameter is very probably to be a mistake that could be fixed during the development cycle. For example, trying to generate a currency formatter without the currency code.

// This Error is preserved.
Globalize('en').currencyFormatter()
// > currency: E_MISSING_PARAMETER: Missing required parameter `currency`.

The above error and all other assertions that happen during formatters and parsers generation should be preserved.

What I am suggesting is that the following don't be considered an error, because it usually happens during the usage lifecycle (not development).

var fmt = Globalize('en').currencyFormatter('USD');

function displayFormatterCurrency(input) {
  return fmt(input);
  // If input is undefined, it would throw the error below (which I suggest to be dropped)
  // > value: E_MISSING_PARAMETER: Missing required parameter `value`.
}

I have been convinced that you don't want your application to halt on an invalid input (user, database, or whatever other source input). Instead it's better to display it's an invalid currency NaN and optionally let your application code to handle such cases.

[sompylasar]

I have been convinced that you don't want your application to halt on an invalid input (user, database, or whatever other source input). Instead it's better to display it's an invalid currency NaN and optionally let your application code to handle such cases.

I assume every input that is considered invalid should be handled explicitly by the app. Otherwise it's an error that should halt the app and report the exception.

Instead of showing NaN to users and not knowing that such error ever happened, I'd better handle an exception in production and send an auto-report about it, and upon receiving the report, I'd add input validation to the next version of the app.

[rxaviers]

cc @dutompson from original issue.

[rxaviers]

Instead of showing NaN to users and not knowing that such error ever happened, I'd better handle an exception in production and send an auto-report about it, and upon receiving the report, I'd add input validation to the next version of the app.

Note apps can still do that regardless of this change.

[rxaviers]

cc @jquery/globalize for input too.

[sompylasar]

Note apps can still do that regardless of this change.

That's not true. After the proposed change there will be no exception to report, so the developer won't know if he made a mistake by not validating input before passing it to external library (globalize).

[rxaviers]

That's not true. After the proposed change there will be no exception to report, so the developer won't know if he made a mistake by not validating input before passing it to external library (globalize).

Now, I think I understood what you're saying. Are you talking about a catch all errors that would auto-report? It would catch a formatter trying to format an empty input because it would throw an error in this case. Please, correct me if I'm wrong.

I'll give some time to hear more opinions about this topic.

[sompylasar]

Now, I think I understood what you're saying. Are you talking about a catch all errors that would auto-report? It would catch a formatter trying to format an empty input because it would throw an error in this case. Please, correct me if I'm wrong.

Yes, exactly.

[sompylasar]

P.S. In production, unexpected inputs and app states happen often, a developer often cannot predict all of them, so it's as important to be notified of them during the "execution stage" as during the "configuration stage" (the latter has got fewer variables that depend on the app runtime state, so it tends to be more tested during development).