reportError could mention other error reporting use cases

[camsteffen]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/reportError

What specific section or headline is this issue about?

The second paragraph starting "This feature is primarily intended for..."

This feature is primarily intended for custom event-dispatching or callback-manipulating libraries. Libraries can use this feature to catch errors in callback code and re-throw them to the top level handler. This ensures that an exception in one callback will not prevent others from being handled, while at the same time ensuring that stack trace information is still readily available for debugging at the top level.

What information was incorrect, unhelpful, or incomplete?

I think reportError is generally useful for reporting errors in application code, particularly if you have telemetry tools like Sentry installed. Or even without telemetry, it could be a reasonable coding style to use it for any case where an error occurs but you don't want to halt the current function. But this paragraph seems to nudge people away from using it unless you are writing a library or some low-level/framework code.

What did you expect to see?

Either include a broader set of possible use cases, or don't prescribe use cases at all. I think it would be enough to merely document behavior.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

[Josh-Cena]

This paragraph describes why this feature was originally implemented. If you have more use cases, you are welcome to add them as examples, but I personally haven't seen it used for telemetry.

[camsteffen]

This paragraph describes why this feature was originally implemented.

Is this referring to some historical conversation when it was implemented?

[Josh-Cena]

Basically—since this page was written as soon as the feature shipped, all use cases the writers could have known are those proposed by the working group. Future use cases could be discovered by users like you, so if you have another use case in real life you are welcome to add it.

[Josh-Cena]

@camsteffen Do you have any use case you want to add to this page? The current description doesn't say "you should use it for X purpose". It says "it was designed for X purpose so obviously X is a known use case". More use cases are welcome, but there's nothing to be changed because we are just stating a fact.

[camsteffen]

My use case is: in a onClick handler, surround some business logic with a try/catch to show an error toast message in case of an error. Use reportError to send the error to Sentry as well as console.error. Re-throwing the error could work except that async uncaught errors cause unit tests (in Jest) to unpreventably fail.

I'm not sure how to reduce that down into something general enough for mdn. Maybe something like, reportError can be used to report errors in application code that are caught but not necessarily recovered.

[Josh-Cena]

That sounds like a good use case. Would you want to add it to the docs?