qzind / tray

Browser plugin for sending documents and raw commands to a printer or attached device.
https://qz.io
Other
845 stars 275 forks source link

Expose stack trace to JavaScript #318

Open tresf opened 6 years ago

tresf commented 6 years ago

For cloud providers, it is requested that we can provide a full java.lang.Exception backtrace from Java to JavaScript when an exception occurs to reduce the number of times the provider has to remote into the client workstation.

This is a placeholder to track the feasibility of this request.

akberenz commented 5 years ago

What about taking advantage of our stream system for this?

Something along the lines of

qz.api.setExceptionCallbacks(function(event) {
  console.log(event.exception);
  console.log(event.message);
  console.log(event.stacktrace);
  // other things ?
}));

We'd have to go through and add a sendStream java-side to all the exceptions we want visibility on, and make sure all sessions get a copy, but it should be possible.

tresf commented 5 years ago

What if we made it promise-driven fetch of the details only when one occurs? The exceptions are already being raised we just need more details.

Perhaps another option is to provide an API for fetching the logs?

I guess any solution may suffer the possibility of the exception being a breaking one and ending the WebSocket communication.

akberenz commented 5 years ago

The problem with a fetch is we either have to have a queue to fetch from or you run the risk of having the exception you actually want to see being overridden by another and being unable to retrieve it without constant polling. Just having an api for fetching the logs instead might be the best compromise though.

If its a crash causing exception though, won't they have to remote in anyway to restart it? Probably not a situation we can respond to anyways, so not one we should worry about for now.

tresf commented 5 years ago

Yeah, that sounds like a good compromise.