Hello everyone. I'm sure at least one of you handles errors by printing something or leaving it by default. It's time to change that! Say hello to awesome-errors! Awesome errors is a library to handle errors with readability and simplicity in mind. Here's an example of how the output looks:
[error]: something went wrong
--------------------------------------------------
=> file:///path/dist/main.js:28
27: try {
28: throw new Error("something went wrong");
29: }
The error is easily shown with the call stack. Here's how to install it:
- Run:
npm install awesome-errors - Import it using
import AError from "awesome-errors" - Try to throw an error like this:
try {
throw new Error("something went wrong");
} catch (error) {
new AError(error);
}
That's it! It was that simple to convert your errors to be more beautiful ✨.
Please leave a star below:
https://github.com/ksawery29/awesome-errors
Top comments (2)
I very much appreciate the intent of this, and in general I completely agree. Especially if you’re making a library, good error messages are really helpful.
We do need to be careful, though. Error messages can disclose the inner-workings of our applications, which can be harmful from a security perspective.
If you have an image resizing web service, “I couldn’t access the image” and “what I accessed wasn’t an image” are both too much information. If I know you couldn’t access the image, I can probe a bit more and hope that I’ll get a different message if I figure out how to trick your program. If you tell me you don’t think my malicious payload was an image, now I know to try and defeat that validation. It would be far better to respond “I don’t know what happened, but I couldn’t fulfill your request,” then I have a lot less to go on in trying to defeat your safeguards.
Cool, keep it up