Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added additional information for error handler #2048

Merged

Conversation

D-r-P-3-p-p-3-r
Copy link
Contributor

Useful when formatting log messages fails. Now you can tell which log message caused the problem.

Useful when formatting log messages fails. Now you can tell which log message caused the problem.
 does not work with wchar_t based string.
There's actually a diffent string view type for wide string...
Mixing char types in libfmt is a problem and WIP.
@D-r-P-3-p-p-3-r
Copy link
Contributor Author

Currently, there's still a problem under Windows with wchars...

@gabime
Copy link
Owner

gabime commented Aug 13, 2021

can you fix it?

@D-r-P-3-p-p-3-r
Copy link
Contributor Author

It's work in progress. I will continue checking it out when I'm back at work next Tuesday.

@D-r-P-3-p-p-3-r
Copy link
Contributor Author

Ok, I found the root cause.

It's actually SPDLOG_WCHAR_TO_UTF8_SUPPORT. The wstring_view_t format string/message can't just be dumped into fmt::format together with the exception message from what() in two versions of log_.

For now, I'm passing an empty string to SPDLOG_LOGGER_CATCH in those two versions of log(). Like that it's no worse than before under Windows.

But I'll still check for a nicer solution next week.

@gabime
Copy link
Owner

gabime commented Aug 13, 2021

Ok. Thanks. I will leave this pr open until fully implemented.

@D-r-P-3-p-p-3-r
Copy link
Contributor Author

I got a working solution now which also works smoothly under Windows. Instead of emitting the offending log message, the location of the offending log message is reported (filename and line).
Thus, finding the problematic log message is still easy, but there is no trouble with wide chars. Also, using the original log message (using wide chars or not), could trigger the same exceptions that the original logging attempt could have. This problem is avoided as well.

if(location.filename) \
{ \
try \
{ \
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think an extra try catch needed here. why would it fail? the lib is in total control of the source loc param

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just figured as fmt::format can throw (e.g. in case of OOM), it would be the safest bet to catch.
I'll remove it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, please remove it and I will merge.

@gabime
Copy link
Owner

gabime commented Aug 17, 2021

Alos please note that by default the source_loc is empty unless the SPDLOG_INFO/DEBUG etc macros are used.

@D-r-P-3-p-p-3-r
Copy link
Contributor Author

Alos please note that by default the source_loc is empty unless the SPDLOG_INFO/DEBUG etc macros are used.

In our case, our own log macros forward to SPDLOG_LOGGER_CALL or add the source_loc themselves. So that's cool.

The fmt::format call should not throw formatting the exception message and the source code location.
@gabime gabime merged commit deb178a into gabime:v1.x Aug 17, 2021
@gabime
Copy link
Owner

gabime commented Aug 17, 2021

Thanks @D-r-P-3-p-p-3-r . Merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants