Global errors handling and reporting

Adobe XD UXP Plugin API
1

Just curious who is using what for errors tracking and global errors handling? Does XD store provide any such functionality? I made attempt to use bugsnag but plugin crashes on start.

1 Like
2

I put try catch around problem areas but no tracking. I came across trackjs today. I haven’t tried if it and don’t know if will work in UXP or not.

If you are on a budget you could always write your own logging in your catch block post the error to a page on your server.

try {
   // try or try not there is no do
}
catch (e) {
    logError(e);
}

function logError(e) {
    // post error to your site
}

Note: You might have to disclose if you post data back to your site.

Also, it looks like there is something called Sentry.

You can capture global errors using the window.onerror event:

But it’s not clear if that is supported in UXP.

I’ve tried the following and there were no results:

function errorHandler (msg, url, lineNo, columnNo, error) {
	var string = msg.toLowerCase();
	var substring = "script error";
	log("ERRORS")

	if (string.indexOf(substring) > -1){
	  log('Script Error: See Browser Console for Detail');
	} else {
	  var message = [
		 'Message: ' + msg,
		 'URL: ' + url,
		 'Line: ' + lineNo,
		 'Column: ' + columnNo,
		 'Error object: ' + JSON.stringify(error)
	  ].join(' - ');
 
	  log(message);
	}
 
	return false;
};

function errorHandler2 (error) {
	log("Errors")
	return false;
};

// trying to catch the errors:
window.addEventListener("error", errorHandler2);
window.addEventListener("error", errorHandler2, true);
window.onerror = errorHandler;
GlobalEventHandlers.onerror = errorHandler;
3

If I got it right window object is an empty object with mocked functions so addEventListener just doesn’t do anything, correct me if I’m wrong.
try…catch doesn’t make much sense as they catch mostly expected exceptions.
Also I slightly don’t follow how it will work in general. All plugins (panels and dialogs) exist in the same window object so if someone write in dialog window.onerror = errorHandler; it will overwrite handler for current active panel.

4 
window.onerror = errorHandler;

is how they suggest to do it in the browser. Well one of a few methods. Yes, that way would overwrite an existing global error handler. UXP probably has one already and it’s what is showing in the Developer console. If this was in production I would add an event listener.

I don’t know that they are the same window object. My plugin can’t get errors from other plugins or vice versa.

5

I’ve changed this to a feature request. Let me know and I can create another post.

For me, it would be great to be able to listen for global uncaught errors for my own case and to prevent them from being shown in the developer console.

The first reason to prevent them from showing them in the console is because in the past text areas with a lot of information can slow down the entire application. Maybe it’s different but I’ve seen this in IDEs and in browsers.

The second reason to prevent showing errors in the console is because the user will never see these messages.

Instead if an error happens in my plugin, I can show an error icon and message in the plug-in panel to inform the user to reload the plugin (in my case).

6

This would be very helpful because it would allow us to use Sentry and track the errors that our customers are having.

2 Likes
7

Any updates on this issue?

2 Likes
8

Here’s hoping for some thread revival, because global error handling would be ideal and seems silly to not support.

While I don’t personally have an answer for the OP related to window.onerror, I can confirm Sentry works. While you don’t get the safety net for things like uncaught exceptions without the global error handler, you can (and should) get pretty good coverage by doing things like reporting to your error monitoring service in a React error boundary and using try/catch around risky code.

try…catch doesn’t make much sense as they catch mostly expected exceptions.

In a way this is true, related to uncaught things/a safety net. But outside of that, intentional error reporting is still extremely valuable. In most cases, a caught error is still an error you want to know about, and often you want to know more context than the error itself would give you if it was uncaught. For example, say you’ve got a switch/case that handles actions:

switch(action){
  case 'expectedAction':
    // do something
    break
  default:
   // Tell your error reporter the value of `action`
   // Report an error
}

or dealing with an API

const config = { 
  // some data that doesn't match what an API needs
}

try {
  const result = fetchFromAPI(config)
  if(result.success === true) log('Success!')
} catch (error){
  // What if the data we supplied caused us to get back `undefined` from the API?
  // This would catch a "Cannot get property `success` of undefined" error, but that isn't useful, 
  // because what we really want to know is that we supplied the wrong config and got a 400 from 
  // the server.
}

Realistically, you should be coding defensively so that when errors occur you can catch them, supply that extra context to your error monitoring service, and provide more helpful feedback to the user than “unexpected error”. A global error handler is helpful from a not-missing-a-thing standpoint, but as an idealistic way of writing code, I personally think your goal should be to avoid uncaught exceptions wherever possible.

Disclosure: I worked for Sentry for 6 years. It’s a great product and I wouldn’t write code without it. That said, there are plenty of alternatives, and I imagine they will work similarly in the UXP environment.

1 Like