You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there an existing issue that is already proposing this?
I have searched the existing issues
Is your feature request related to a problem? Please describe it
I find it not super convenient having to combine both critical application errors (e.g. application code bug, or application logic bug) AND user interaction errors (e.g. user trying to do something not supported by the application, or perhaps bad user inputs even though those could be mapped to less critical log levels such as verbose, debug, info or warn..).
Describe the solution you'd like
A new 'fatal' (or 'critical') log level introduced and leveraged in the default ootb nestjs logger classes (Logger, ConsoleLogger, LoggerService, etc), which would now allow to easily differentiate/isolate application 'fatal' from 'error' problems.
Very simple doc update to introduce a new method signature in the LoggerService code snippet listed here.
No migration strategy needed, since this remains backward compatible, e.g. no breaking change introduced. Users can simply start leveraging the new 'fatal/critical' log level, if they want/need to. All their existing code relying on all other existing and kept log levels will still work.
What is the motivation / use case for changing the behavior?
In the end, if ALL application errors end up being identified all the same, e.g. under ERROR log level, then it makes it hard for us apps developers to quickly identify which of all these potential errors are actual critical unrecoverable application errors that require our immediate attention and will require actual application code or configuration fix or else they'll continue to generate errors to users trying the same functionality.
The text was updated successfully, but these errors were encountered:
Apache Log4j uses this standard and as @Frank-D said, the Fatal level error is used to prevent the application from continuing and allow to easily differentiate/isolate application 'fatal' from 'error' problems.
Could we add this fatal level error? I have never contributed to NestJS and I would like to, can I?
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
I find it not super convenient having to combine both critical application errors (e.g. application code bug, or application logic bug) AND user interaction errors (e.g. user trying to do something not supported by the application, or perhaps bad user inputs even though those could be mapped to less critical log levels such as verbose, debug, info or warn..).
Describe the solution you'd like
A new 'fatal' (or 'critical') log level introduced and leveraged in the default ootb nestjs logger classes (Logger, ConsoleLogger, LoggerService, etc), which would now allow to easily differentiate/isolate application 'fatal' from 'error' problems.
Teachability, documentation, adoption, migration strategy
Very simple doc update to introduce a new method signature in the LoggerService code snippet listed here.
No migration strategy needed, since this remains backward compatible, e.g. no breaking change introduced. Users can simply start leveraging the new 'fatal/critical' log level, if they want/need to. All their existing code relying on all other existing and kept log levels will still work.
What is the motivation / use case for changing the behavior?
In the end, if ALL application errors end up being identified all the same, e.g. under ERROR log level, then it makes it hard for us apps developers to quickly identify which of all these potential errors are actual critical unrecoverable application errors that require our immediate attention and will require actual application code or configuration fix or else they'll continue to generate errors to users trying the same functionality.
The text was updated successfully, but these errors were encountered: