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

Custom errors thrown in onRequest are not usable when caught in onError in 1.1.6 #779

Closed
nathankleyn opened this issue Aug 14, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@nathankleyn
Copy link
Contributor

nathankleyn commented Aug 14, 2024

What version of Elysia is running?

1.1.6

What platform is your computer?

Darwin 23.6.0 arm64 arm

What steps can reproduce the bug?

import { expect } from "bun:test";
import Elysia from "elysia";

class SomeCustomError extends Error {
  asJSON() {
    return JSON.stringify({
      somePretty: "json",
    });
  }
}
const app = new Elysia()
  .onError(({ error }) => {
    if (error instanceof SomeCustomError) {
      return error.asJSON();
    }
  })
  .onRequest(() => {
    throw new SomeCustomError();
  })
  .get("/", () => "");

const res = await app.handle(new Request("https://localhost/"));
const body = await res.json();

expect(body).toStrictEqual({
  somePretty: "json",
});

What is the expected behavior?

The error parameter to the onError hook should be the error that was thrown.

What do you see instead?

The error parameter is a function named S1 and isn't the error that was thrown:

[Function: S1]

Additional information

This works in 1.1.5, not in 1.1.6.

It works when aot: false.

Have you try removing the node_modules and bun.lockb and try again yet?

Yes

@nathankleyn nathankleyn added the bug Something isn't working label Aug 14, 2024
@nathankleyn nathankleyn changed the title Custom errors thrown in onRequest are not usable when caught in onError Custom errors thrown in onRequest are not usable when caught in onError in 1.1.6 Aug 14, 2024
@SaltyAom
Copy link
Member

Should be fixed with 2085673 with test case included, published under 1.1.8

Feels free to reopen or create a new issue if the problem still persists, thanks.

@nathankleyn
Copy link
Contributor Author

nathankleyn commented Aug 27, 2024

Thank you so much @SaltyAom, can confirm this fixed the issue on our side and we've upgraded to 1.1.8 successfully. Huge thanks to you for the fix and this amazing project 🙇‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants