Losing stacktrace on error during compound tag write

[HoldYourWaffle]

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:

minecraft-launcher-core-node/packages/nbt/index.ts

Lines 332 to 343 in 6b9dc80

	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]

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]

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

[ci010]

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]

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]

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]

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.