Skip to content
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

Losing stacktrace on error during compound tag write #127

Closed
HoldYourWaffle opened this issue Mar 27, 2020 · 6 comments · Fixed by #131
Closed

Losing stacktrace on error during compound tag write #127

HoldYourWaffle opened this issue Mar 27, 2020 · 6 comments · Fixed by #131

Comments

@HoldYourWaffle
Copy link
Contributor

When debugging #125 I noticed that stacktraces get lost if an error occurs when writing a compound tag. Instead of a helpful pointer to offending code, I got the following error from jest:

● NBT › #serialize › default › async

    Failed: Object {
      "message": "Require LongArray but found object",
      "type": "IllegalInputType",
    }

      133 |                 //expect(value).toStrictEqual(src);
      134 |             });
    > 135 |             test("async", async () => {
          |             ^
      136 |                 const src = new TestType();
      137 |                 const buffer = await serialize(src, { compressed: compress });
      138 |                 //expect(buffer).toBeTruthy();

      at Env.it (node_modules/jest-jasmine2/build/jasmineAsyncInstall.js:89:24)
      at testNBT (packages/nbt/test.ts:135:13)
      at Suite.describe (packages/nbt/test.ts:154:13)
      at Suite.describe (packages/nbt/test.ts:153:9)

As you can probably imagine, this wasn't a fun one to debug 😓
The offending code:

try {
buf.writeByte(tagType);
writeUTF8(buf, key);
writer.write(buf, value, childContext);
} catch (e) {
if (e instanceof TypeError) {
throw {
type: "IllegalInputType",
message: `Require ${TagType.getName(tagType)} but found ${typeof value}`,
};
}
}

I think the stacktrace is lost because a 'plain object' is thrown instead of an actual Error. (I didn't even know you could do that, although I'm definitely not surprised.)

The (false) stacktrace that's listed in the log points to jest code that creates an Error instance. This is probably the error that causes the actual message in the log, thus creating a false stacktrace.

@ci010
Copy link
Collaborator

ci010 commented Mar 27, 2020

Yes, unfortunately, the error handling in all packages are unified and not throwing Error. That's a kind of "historical" problem. You can definitely change the throw into the Error that makes more sense.

@HoldYourWaffle
Copy link
Contributor Author

In that case I'd propose completely removing the surrounding try-catch. Is that okay with you?

@ci010
Copy link
Collaborator

ci010 commented Mar 27, 2020

In that case I'd propose completely removing the surrounding try-catch. Is that okay with you?

Well, I suggest you to wrap another error containing the same fields with the original one.

@HoldYourWaffle
Copy link
Contributor Author

Hold on, I don't think I understand. You want to wrap the error, inside another error. Why would you want to do that?
Sorry if this is a stupid question, I haven't done much error handling in node yet.

@ci010
Copy link
Collaborator

ci010 commented Mar 28, 2020

Hold on, I don't think I understand. You want to wrap the error, inside another error. Why would you want to do that?
Sorry if this is a stupid question, I haven't done much error handling in node yet.

They major reason I catch and rethrow here, is because this error occurred during user use the API correctly, but maybe the pass-in data is not valid.

And I don't want the error diving into the ByteBuffer code. It's fine to throw here and tell user "hey, some of the field's type is not matched. You just expect the type is aaa but you pass-in bbb" and then user will know this is a use case error, not a bug or something...

@HoldYourWaffle
Copy link
Contributor Author

Oooh I get it. You just want to throw a new error. I thought you meant "wrapping" in the sense of Java's "caused by" mechanism, which confused me.

I'll create a PR for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants