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? |
|
There was some custom code added earlier to PK that affected the error reporting. I think that code is a temporary hack. A proper solution means a review of 4 concepts:
|
Most programs (that I am aware of) don't do such smart switching. They either have two formats (one for interactive, one for non-interactive), or a single one (which is used everywhere). Adding multiple ways to switch context and information "density" for errors could be adding unnecessary complexity to the program.
I'm not sure if I mentioned this somewhere before, but we can display a small one- or two-liner error on the user-facing side of PKCLI, and the detailed message can be printed in the logger. While it would blow up the size for the logs a bit, it would be useful separation to differentiate between information useful to end-users and information useful for developers. I have done something similar for an application I am working on. Any errors are printed with error formatting. This is kept concise to allow for users to correct their usage. Due to the lack of an explicit logging system, I just print the traceback with a debug level. If the user experiences an error which is not triggered by improper usage, they can either check a file for detailed logs, or reproduce the issue with logger set to debug level to show the traceback. As we have a proper logger, we can print the detailed error via the logger while a concise error is shown to the users. $ chroma load tokyodark
EROR LuaError - /home/aryanj/Projects/chroma/chroma/builtins/colors.lua:7: attempt to call a nil value (upvalue 'fn')
EROR Report this at https://github.com/aryanjassal/chroma/issues
$ chroma load tokyodark -v
EROR LuaError - /home/aryanj/Projects/chroma/chroma/builtins/colors.lua:7: attempt to call a nil value (upvalue 'fn')
EROR Report this at https://github.com/aryanjassal/chroma/issues
DBUG Traceback (most recent call last):
DBUG File "/home/aryanj/Projects/chroma/pip_packages/bin/chroma", line 8, in <module>
DBUG sys.exit(main())
DBUG ^^^^^^
DBUG File "/home/aryanj/Projects/chroma/chroma/main.py", line 141, in main
DBUG theme.load(
DBUG File "/home/aryanj/Projects/chroma/chroma/theme.py", line 98, in load
DBUG c = config["generators"]["generator_modes"]["background"](ColorHex('#ffffff'))
DBUG ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DBUG File "lupa/lua54.pyx", line 946, in lupa.lua54._LuaObject.__call__
DBUG File "lupa/lua54.pyx", line 1918, in lupa.lua54.call_lua
DBUG File "lupa/lua54.pyx", line 1945, in lupa.lua54.execute_lua_call
DBUG File "lupa/lua54.pyx", line 1826, in lupa.lua54.raise_lua_error |
The smart switching is done by checking the stderr pipe type. I've seen this functionality. |
Distributed logging and tracing collectors need to collect in a single line. |
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: