Structured formatting of errors when converted to string #21
Comments
|
before I proceed with this we need to settle with a format. In the trivial sense I could just make the We have the format I made already which is a lot more concise if missing some information. I think there's an inbetween where we use the JSON structure but strip out some extra information like the call stack. @CMCDragonkai thoughts? |
|
Can you review the issues here: https://github.com/MatrixAI/js-logger/issues |
|
I don't like the The thing is I guess is that we have error log and warning log that may sometimes be the result of an exception object. That error chain specified in this repo, needs to then be converted appropriately in the js-logger, especially because we are crossing boundaries from object representation to string representation. Serialisation of the object already has a standard, that's what the JSON thing is for, and should be used for when we log out with JSON format. Human readable representation does have a similar concept - I think we can preserve the singular message and not change that, there's a reason for this. However additional structured information could be reported with tags, and again should be part of the logging format/verbosity flags. I say keep the messages as is. And spec out a format symbol for additional key:value information. |
|
Based on discussion yesterday, we're going to scrap the custom |
|
I will be taking this over as it is related to Polykey#824 |
|
Now that we are using Polykey ( This is too verbose compared what we had before, and 6/8 lines are useless in this context. While our method (the verbose one) is exceptionally useful for developers, it is unnecessarily verbose for end users. It would be similar to sharing the full traceback for the error, which could look like this for the So, instead of having a verbose error to aid in debugging, the error should instead be concise for the user, and be verbose in the logs. In this case, the concise error could be printed out to the user, and the verbose error (the error formatting we currently have) can be printed out in the logs. Users can attach their logs, which we could use to correlate and find the issue. For rendering, instead of trying to show multiple levels of error, we can just show the topmost error (in case of Alternatively, if we need to show some errors to the user, they can be rendered as such. Do note that I have changed the error formatting from I'd say the current state of the errors are trying to be extremely useful for developers, which makes them difficult to understand and work with for end users. As such, we need to reduce the error to a single line (for most cases) for the end user. A product should be sufficiently complex for power users while being easy to use by beginners. |
This is intended formatting and I think we should stick to it. It is a little verbose though. This issue is focusing on how the errors are formatted when converted with How they are formatted when handled by the CLI formatter is out of scope for this. |
|
Then I'm not sure what this issue requires.
Is this all we need to work on for this issue? |
Specification
In MatrixAI/Polykey#828 I added some code to format the errors in a way that included the cause chain within the error. The intention of this was to get the full context of an error. Especially when it was wrapped in a generic
PolykeyRemoteError.Additional context
Tasks
js-errorsThe text was updated successfully, but these errors were encountered: