Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Clarify how to handle all fatal errors

See original GitHub issue


I’ve been working on an internal library that tries to wrap the CometD Java client into a Reactor Flux. Part of this involves propagating all possible fatal events (terminal failures, server sent disconnects) as errors.

I’ve registered the necessary callbacks on handshake and subscribe as suggested in the manual - and thanks for documenting that!

The problem is that wasn’t quite enough. I’ve also had to override the BayeuxClient’s onTransportFailure(String, String, Throwable) method in order to handle fatal internal errors when there are no more transports to fall back on (eg. a handshake failure where the advice is ‘none’, or exceeding the max backoff time). I’ve also had to define an extension to handle server initiated disconnects, which while not being errors are fatal to the BayeuxClient.

If anything above seems obviously wrong or if there’s an easier way to capture all errors, please let me know. If not, I have some recommendations:

  • For now, documenting the need to override onTransportFailure to handle internal issues would be awesome. The documentation already covers using callback methods to handle handshake and subscription failures, so this would fit right in. Same goes for clarifying that server sent disconnects need to be handled, and maybe even having an example of an extension that would server.
  • In future versions, it might make sense to take a page from Reactor and define callback registering methods directly on the BayeuxClient. It’d be more consistent than overriding (since we already use callbacks to handle handshake/subscribe issues) and allow us to define handlers like onFatalError, onTerminate, and onServerDisconnect to make it easier to ensure you have all your bases covered. I think onTerminate is particularly powerful, since “do this thing if the BayeuxClient is dead and not coming back” strikes me as likely to be a very common use case.

Thanks, and let me know what you think.

Issue Analytics

  • State:open
  • Created 5 years ago
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

sbordetcommented, Sep 5, 2018

I’ve already integrated BayeuxClient 3 with the Reactor library, so doing it for a generic Publisher with version 4 shouldn’t be too dissimilar I hope.

Is this public so I can take a look?

sbordetcommented, Jul 21, 2018

I’ve also had to define an extension to handle server initiated disconnects, which while not being errors are fatal to the BayeuxClient.

It should have been enough to register a /meta/disconnect listener, I think?

allow us to define handlers like onFatalError, onTerminate

What would be the difference between the two above? I agree that an onTerminate callback would be useful although is definitely not the common case (the common case is that everything works and BayeuxClient can communicate with the server).

We’ll probably do some similar work (ReactiveStream-ing BayeuxClient) for CometD 4, so your input/contributions will be great.


Read more comments on GitHub >

github_iconTop Results From Across the Web

Which errors should I handle? Which ones are "fatal"?
I would like to handle all "non-critical" errors (such as bad file names), while allowing "critical errors" (such as access violations) to ...
Read more >
What is Error Handling? - Definition from Techopedia
Error handling refers to the response and recovery procedures from error conditions present in a software application. In other words, it is the...
Read more >
A Definitive Guide to Handling Errors in JavaScript - Kinsta
This article will guide you through the basic errors in JavaScript and explain the various errors you might encounter. You'll then learn how...
Read more >
Exceptions and debugging - Advanced R. - Hadley Wickham
Debugging, condition handling, and defensive programming · Fatal errors are raised by stop() and force all execution to terminate. · Warnings are generated...
Read more >
Clarifying Failure as a Path to Success - The Mountaineers
Ensuring all of our students and instructors knew which critical applications were fail-worthy would help clarify the learning process and ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found