Console errors showing up in create connection pages

[syndesis-bot]

@gashcrumb	2017-11-14	bug

@kahboom wonder, do we need to just catch these errors or dispose of the tour service instance? Not sure...

[syndesis-bot]

@kahboom	2017-11-14

I think it would be good to catch the errors, as they are valid and could be helpful. I'll fix this specific issue today and will think about how to best handle the errors after.

[dsimansk]

I've spotted the same error and Connection not loading properly on list page. Unfortunately it blocks creation of new connection until Connection page is reloaded manually.

vendor.40d7cdfd283ceb4a2840.bundle.js:1 ERROR Error: anchorId connections.available already registered!
    at new g (polyfills.fa9f9d475a3e25dd29a3.bundle.js:1)
    at e.Nynv.t.register (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at e.Nynv.e.ngOnInit (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at Cn (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at dr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at cr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at jr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at Object.g.ɵvid.e [as updateDirectives] (0.4c0edb16b51fbd7ed1c0.chunk.js:1)
    at Object.updateDirectives (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at ur (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at Cr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at wr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at ur (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at Cr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)
    at wr (vendor.40d7cdfd283ceb4a2840.bundle.js:1)

[deeleman]

I've spotted the same error and Connection not loading properly on list page.

@dsimansk: Please make sure your branch is up to date with the latest changes. I merged a fix for that along with the Change Detector refactor last Friday.

I think it would be good to catch the errors, as they are valid and could be helpful.

Indeed, but let me remark that we should escape away from try/catch constructs as much as we can. Those have a negative impact on application performance and covering exceptions up like that does not help to better detect and debug issues.

There is not much we can do when it comes to mismatches between template and component class bindings (that case scenario will always incur in an unhandled exception no matter what), but for the rest of cases, Angular already provides a centralized way to intercept and handle errors by means of the ErrorHandler internal provider.

For the sake of a better exception handling experience, we should override that class with our own SyndesisErrorHandler provider at the AppModule level, implementing our own handleError(error: any) method to better digest and handle errors, allowing the application to degrade gracefully and carry on. Something like this would help:

@Injectable()
export class SyndesisErrorHandler implements ErrorHandler {
  handleError(error) {
    log.errorc(error); // Or our very own logger provider
  }
}

And then, at AppModule:

@NgModule({
  declarations: [AppComponent],
  imports: [
    // ...
  ],
  providers: [{
    provide: ErrorHandler,
    useClass: SyndesisErrorHandler // <=== Look Ma! App is now more resilient! ;D
  },
  // ...
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

This is part of the proposed changes in the Angular 5/6 epic, as part of the DEBUG mode.

[dsimansk]

@deeleman well it seems that syndesis-ui:latest on Dockerhub was published 5 days ago. I'm definitely not on a truly latest version then. Let my look into the CI job a bit closer.

[deeleman]

All right. I believe it is safe to close this issue in the meantime.