I wrote a simple Error wrapper for production

Hi folks, I hope you are doing well,

I wrote a simple custom Error, the purpose is to avoid big loads of logs in production environments. I never thought of this problem: what if an error is stuck in a loop somehow, the whole disk would be filled in minutes.
Until I went to prod. But then I was kinda surprised why there are no solutions to this? Nobody is facing such problem or am I missing something?

So this is my solution I want to discuss earlier motivation and my solution itself, I know you guys here would easily suggest V2.

ps: I never said it but don't forget to smash the like button :joy::joy::joy:


Looks like there is a memory leak. The history array keeps growing without a limit.

1 Like

Thanks for reviewing
it is true I will fix that, events prior to window have no reason to stay. But still it could theoretically grow with no limit, but I think the root problem we are trying to solve, when errors happen inside of a loop, I will look on that

I don't see why you'd use an Error subclass for that. Inheritance seems to be the wrong tool here. What if you had an exception that was not a LogSafeError? It would still fill up your disk.
Instead, you should approach this problem in the logging library that actually writes all the (different kinds of) errors to those files. And also, use log rotation of course.

I understand @bergus , the reason is that I can't propose this for every logging library, I suggested to pino.js but it seems it's a specific use case and up to user to implement these. So I thought of a generic one. Then Inheritance comes. Also the user error does not have to be a LogSafeError, it can just be wrapped this way: throw new safeLogger1(error) keeping your usual logger do the rest.

Because developers themselves log errors they totally can wrap there errors with this. Of course you can't catch everything, but those you are not logging anyway.

Can't you like do the thing you wanna do in a different way? Ideally, write the program in a way that it doesn't have to throw so many of the same error over and over again.

Because you simply can't have full control over every library you will be using

Sounds like this is a logging concern, not an error concern. Where do you intend to use it anyway, to use this error, you have to have control of the errors thrown by the library?

1 Like

I'm not suggesting this as a JS feature. I just shared two lines of code for anyone interested