Open mir3z opened 6 years ago
Is handleExceptions: true on a transport supposed to be equivalent to setting an exceptionHandler? I don't get why there are two completely parallel ways to achieve the same thing, except perhaps to enable you to have a general logger which also handles exceptions (as opposed to defining a separate one)
This used to work on winston@2
(formatting of exception handlers), I don't understand why formatters don't work on winston@3
.
You are facing the same problem with me. I think the root cause was about winston-transport
that when we set its format
it will recreate an info object which mean an Error
instance will be lost the identity.
transformed = this.format.transform(Object.assign({}, info), this.format.options);
Should we handle more about error case on this?
ran into this issue as well. naively, it looks like an issue with the way things are being proxied through ExceptionStream
. since this calls log
on the underlying transport it skips the transform
call in TransportStream#_write
.
not totally sure the cleanest way to address this, but it seems like this could be fixed by turning ExceptionStream
into a duplex and piping it into the underlying stream, or maybe placing a transform
call in TransportStream#log
.
I faced with the same issue. Winston v3.8.1 still with this behaviour :(
Please tell us about your environment:
winston
version?winston@2
winston@3
node -v
outputs: v8.11.2What is the problem?
I'm trying to understand how does exception handler work and -- belive me -- it's not easy.
Consider the code:
and it prints me JSON:
Next step - let's add a formatter:
now it prints a nicely formatted message:
Now let's move formatter to the transport level:
And what now? I still got JSON without formatted message.
But this is not the end. Let's now remove
exceptionHandlers
and addhandleExceptions: true
to console transport:And guess what - formatting suddenly started working! Isn't it magic?
What do you expect to happen instead?
I expect to have working formatters at any level