-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: inject JS stack into errors originating from native code #3653
Comments
This error is part of a class of errors that are thrown asynchronously from within C++ code where there is no access to the current JS stack. To support a stack on errors (which would include everything up to and including the As for which formats are supported, we should probably direct people towards inspecting sharp.format themselves. |
should I then replace all calls of |
It does not really matter to which API we direct users in the error message. Main point there is something in this message, which helps to fix the actual error. |
The return value of |
my scenario is a bit different. I don't call toBuffer or toFile immediately on the instance. For example: const sharp = require('sharp');
async function main() {
let img = sharp(Buffer.from('12345'));
if (1) {
img = img.resize(100);
}
return await img.toBuffer();
}
(async () => await main())(); This code crashes node with unhandled exception:
|
Changing |
Input is evaluated lazily when output is requested. The constructor returns a |
I'm still not quite sure the exception should be passed to node's triggerUncaughtException. Just to compare: const sharp = require('sharp');
async function test() {
throw new Error();
}
async function main2() {
return await test();
}
async function main1() {
let img = sharp(Buffer.from('12345'));
return await img.toBuffer();
}
(async () => await main2())(); main2 prints
while main1 prints
even though |
You'll need to add some kind of error handling to anything that returns a Promise as Anyway, we've gone way beyond the original suggestion, which was to include the |
If an app has multiple Sharp calls, the error message should indicate the place where there was an exception. I can wrap all the Sharp calls with such try{}catch:
but I suppose Sharp itself should wrap a native text exception into a JS exception with a stack trace. |
I think this is probably a price worth paying. If you are suggesting that this is too expensive at runtime, maybe it could be opt-out? I think most users will see an error as an exceptional case and want clear logging, even if it is slightly computationally expensive. At present, if applications have multiple Sharp operations in a pipeline, and an error is thrown, then the maintainers cannot tell which of the operations failed, as all Sharp errors have no stack trace. |
v0.33.0 is now available with a |
Feature request
What are you trying to achieve?
The current error message thrown for unsupported/broken images (
Error: Input buffer contains unsupported image format
) would be more helpful if it had the list of supported image formats in it. Also, Node.js shows no stacktrace for such errors.When you searched for similar feature requests, what did you find that might be related?
Simply init sharp with some random data:
What would you expect the API to look like?
The error message could look like:
Input buffer contains an unsupported image format. Only the following image formats are supported: PNG, JPEG, WEBP
, so users could easily fix the input data themselves without checking additional documentation.As far as I can see the exception itself is thrown inside of native code. Not sure if something special needs to be done for it, so a proper stacktrace is shown (btw I run Node.js 16@macOS 13.3.1).
What alternatives have you considered?
See above
Please provide sample image(s) that help explain this feature
See above
The text was updated successfully, but these errors were encountered: