Errors not shown - How to workaround non-existent `onunhandledrejection`

Photoshop
,
22

Thank you very much for detailed explanation. Now it makes much more sense.

The utility wrapper is what I have right now. Probably not perfect but it helps.

export async function catchPromise<T>(fn: Promise<T> | T): Promise<T> {
	try {
		return await fn;
	} catch (e) {
		Log.error(e)();
		Sentry.captureException(e, {tags: {myTag: "catchPromise"}});
		await alert("Error: " + e);
		throw e;
	}
}

I have about 888 async functions in 323 files in my project. But much more functions will be converted to async. And this does not count built-in function in uxp and ps modules or third party libraries.

And await is used 2397× in 320 files in my project.

And my utility wrapper is only used 71× in 14 files. So only 2326 places remaining more or less I guess? (if I won’t write new code… and I will write it)

Having try/catch inside each async function would be 1438 fewer places than wrapping each call of that function.

And this only applies if I won’t use 3rd party libraries. But I do. And modifying all 3rd party libraries… not good.

And this is only one project… although the bigger one.

And even if I do that how can I be sure to not forget any place? Or my co-worker?

Maybe I could modify “no-floating-promise” es-lint rule to show me error in VSCode and fail to bundle code if something is not handled. eslint-plugin-no-floating-promise/lib/rules/no-floating-promise.js at master · SebastienGllmt/eslint-plugin-no-floating-promise · GitHub

I think we can agree it all sounds like an awful workaround.

UXP got into InDesign and more apps are ahead… Premier? After Effects? maybe Illustrator… more plugins 1st and 3rd party. Is Adobe going to use same workaround for each host app for all 1st party plugins? I think nobody in Adobe wants to deal with errors that cannot be tracked.

Regarding to N-API. Should I/you raise feature request here? GitHub - nodejs/node-addon-api: Module for using Node-API from C++ What exactly should I ask them to do? Can you contribute a code there?

One alternative could be to use Webview for as many plugins and code as I can and turn UXP only into a bridge between Photoshop and Webview, losing some advantages and complicating code. But if everyone does so, it defeats one of the reasons why UXP exists in the first place: performance/memory consumption.

2 Likes
23

I think I will try writing a Babel/TS-Loader/Webpack plugin that will be part of the Webpack bundler config. This would be done automatically without requiring me to pollute the source code and hopefully maintain source maps.

I think Babel should work with pureJS and also should be handle to adjust external node_modules although it would take ages to transform node_modules :smiley: :-/

I am unsure whether I will share the code or keep it private.

24

I think I will try writing a Babel/TS-Loader/Webpack plugin that will be part of the Webpack bundler config. This would be done automatically without requiring me to pollute the source code and hopefully maintain source maps.

The same workaround came to my mind. I am convinced that you are the better analytical programmer of the two of us in this kind of areas, so I would very much appreciate if you would share your work with us :wink:

25

I think you can try it here: https://astexplorer.net/

Select babel/parser and set transform to parser… then you should see how your transform would change source code output. It works with an abstract syntax tree.

2 Likes
26

I have a working Babel plugin that wraps the content of each async function into a try/catch block. It does not break source maps and is not visible in mapped code, so it is fine. Now, I have to do only fine tuning and testing. It wasn’t that hard…

3 Likes