Maybe capture error & warn instead of throw?

[longlho]

Hi @ericf ,

Quick question/suggestion: on this line react-intl actually throws error for invalid input. Is this by design? If yes any chance we can be a bit more forgiving and warn instead of throw? The reason is that this gets bubbled up and croak the server/create unexpected behavior on client and with the React stack trace bloat it's incredibly difficult to trace it.

Thanks!

[ericf]

Yes this is intentional, it's an early throw since the underlying Intl.DateTimeFormat() that will be called will throw if the value is not finite.

There's other discussions that have brought up error/warn handling — so we're thinking about it.

[longlho]

@ericf possible to support a default/fallback prop of some sort? I'm happy to push a PR too if it's cool.

[ericf]

I don't understand what you're proposing… can you explain in more detail?

[longlho]

oh so something like <FormattedDate value={foo} default="N/A"/> which would print out N/A if foo is invalid

[longlho]

ping @ericf :)

[ericf]

What are the actual real-world use cases where you're seeing <FormattedDate> throw? Also, how do you deal with these sorts of exceptions for other data that you try to render in your React components that might be null or something?

[longlho]

@ericf The real world use case is rather simple: Say I fetch some data from the server that has a field called date, which subsequently gets rendered out via <FormattedDate value={date} />. Now if date is a correct representation of a Date of some sort, everything's happy.

However, if date is undefined, new Date(undefined) per this line will result in an Invalid Date, which throws at this line and on the server side, the process got shut down due to Uncaught Exception. 😢

Currently to overcome this issue we have to wrap FormattedDate inside a component like SafeFormattedDate that does a try catch, and that goes for FormattedTime, FormattedMessage and such...

For other React components, if given an invalid data type it would just render nothing (null/undefined) so since the throw was by design, supporting a default prop in FormattedDate would be a more forgiving opt-in alternative for this behavior.

[ericf]

uses React.PropTypes.any.isRequired so you should be seeing warns from React. My main worry is about silent failures, but I see you're point about rendering null being a reasonable thing to do in this case.

[ericf]

See: #162