Effect error logging should be customizable or use ErrorHandler

[jbedard]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[X] Feature request
[ ] Documentation issue or request

What is the current behavior?

Errors are sent to the internal ErrorReporter which logs to the console

Expected behavior:

Errors should be logged to ErrorHandler (from @angular/core) or ErrorReporter should be public and customizable/overridable to allow doing so (or both).

Version of affected browser(s),operating system(s), npm, node and ngrx:

4+ ?

Other information:

Personally I'd think just sending all errors to ErrorHandler would be best and the ErrorReporter can be removed, but maybe others depend on the console logging from ErrorReporter? Maybe just making ErrorReporter public/overridable is a good start without any breaking changes?

[jtomaszewski]

Related question: Is it possible to override ErrorReporter injected by ngrx effects? Like, can I do sth like providers: [{ provide: ErrorReporter, useClass: MyOwnErrorReporter }] in my ngmodule?

[jbedard]

Not while ErrorReporter is private, unless you really want to import and override ɵh.

[brandonroberts]

Exposing the ErrorReporter so you can override it seems reasonable to me. Any takers on a PR?

[jbedard]

I can do it. However I do question what the point of ErrorReporter is. Can we just delete it and use ErrorHandler instead?

[jbedard]

How should this be exposed?

1. make ErrorReporter public
2. replace ErrorReporter with ErrorHandler from core
3. expos errors some other way such as an Observable on EffectSources, maybe keeping ErrorReporter as a default observer of those errors

I'd would vote for 2 because it's mainly just deleting stuff, and I think that's what 99% of people would want... errors logged to the angular-standard ErrorHandler with no extra effort/hookup/integrating. It can maybe be a custom extension of Error so it can be typed and easily filtered by type?

Note that all of these make the error-information public.

[brandonroberts]

I vote for option 1 as its not a breaking change. If you want to override the ErrorReporter with the ErrorHandler or use some other service to capture errors it will be possible to do that.

[jbedard]

How about also changing ErrorReporter to have the same interface as ErrorHandler then? That way ErrorHandler can be a drop-in replacement without any wrapper classes being required...

[brandonroberts]

Sounds good to me