Add class name output to formatter for std::exception #3076

phprus · 2022-09-02T17:50:11Z

phprus · 2022-09-03T09:30:53Z

Rebased and fixed bug related to GCC < 5.

phprus · 2022-09-03T10:52:48Z

Baardi · 2022-09-03T12:54:29Z

I think this type of formatting looks good for exceptions, considering how important the exception type is, e.g. when logging errors.
It also looks consistent with the c# way of formatting exceptions, except for the callstack, which wouldn't be possible to include anways. Not that c++/fmtlib necessarily have to follow other languages on everything.

c# with string.Format on the left, c++ with fmtlib to the right

I guess the main issues would be that it locks support to the main compilers + and that the output isn't completely consistent, which I guess would violate the point below.

ref:

vitaut

Thanks for the PR!

vitaut · 2022-09-04T14:38:20Z

include/fmt/core.h

+  FMT_CONSTEXPR_CHAR_TRAITS bool starts_with(
+      basic_string_view<Char> sv) const noexcept {
+    return size_ >= sv.size_ &&
+           std::char_traits<Char>::compare(data_, sv.data_, sv.size_) == 0;
+  }
+  FMT_CONSTEXPR_CHAR_TRAITS bool starts_with(Char c) const noexcept {
+    return size_ >= 1 && std::char_traits<Char>::eq(*data_, c);
+  }
+  FMT_CONSTEXPR_CHAR_TRAITS bool starts_with(const Char* s) const {
+    return starts_with(basic_string_view<Char>(s));
+  }


Could you move this to a separate PR and add unit tests?

@vitaut
Rebased after merge #3080

vitaut · 2022-09-04T14:52:27Z

I guess the main issues would be that it locks support to the main compilers + and that the output isn't completely consistent, which I guess would violate the point below.

Hmm, that's a good point.

phprus · 2022-09-04T15:13:34Z

@vitaut
Visual Studio ABI and Itanium ABI will show human-readable names.
Other ABIs will show compiler-specific (mangled) names. But other ABIs are rare.

vitaut · 2022-09-06T21:15:46Z

I think we should keep the default format independent of ABI. Let's make type output an opt-in via a separate specifier (maybe t?)

phprus · 2022-09-07T05:13:50Z

Like range format specifications:
Spec: {:t:OtherStringSpec}, Out: exception_class: exception message
or
Spec: {::OtherStringSpec} or {::} or {}, Out: exception message
?

phprus · 2022-09-07T08:35:33Z

@vitaut
Implemented.

Baardi · 2022-09-09T17:36:31Z

I think we should keep the default format independent of ABI. Let's make type output an opt-in via a separate specifier (maybe t?)

I like the idea. It makes sense to format the content of an item by default, which I guess would be the .what() on exceptions.
And for exceptions it also makes sense to provide and easy way to format the type, considering how important it is.
While I think in general it would be better to provide the type by default in exception-formatting, it makes sense to drop it, as there's no standardized way to format the type.

Btw @phprus, with the current PR, it still formats the whole typeinfo.name(), even if it's not one of the "big 3" compilers.
Is there any way to avoid specifying the type-formatter if it's not a "supported ABI"? The reason I wonder, is because the user would then be free to specify a better formatter himself

vitaut · 2022-09-09T17:46:51Z

Please don't use : in format specs because it will interfere with ranges. I think t should be a presentation type specifier like s for strings. We don't really need to combine it with other presentation specifiers.

phprus · 2022-09-09T17:50:43Z

@Baardi
I think the formatter should always be defined.
typeinfo.name() will return the mangled name for any ABI. I think that if the rules for demangling the name are not known, then it is better to output it unchanged.

Baardi · 2022-09-09T18:02:58Z

@Baardi I think the formatter should always be defined. typeinfo.name() will return the mangled name for any ABI. I think that if the rules for demangling the name are not known, then it is better to output it unchanged.

Good point. There's argument both ways. I guess that not specifying the formatter could lead to unexpected exceptions etc,, when trying to write cross-platform code, which would be a good argument for always speciyfing it. And I guess "important" platforms could always create PR's adding proper formatting, if they're not happy with the current way it is formatted.

Anyways, regardless of whether this gets merged or not.
Thanks @vitaut for creating an excellent formatting library, and thanks @phprus for implementing my idea, it would've taken significantly more time for me to create a PR.

phprus · 2022-09-09T18:33:42Z

@vitaut
Implemented.

vitaut

Mostly looks good. A few comments/questions inline.

vitaut · 2022-09-10T02:23:55Z

include/fmt/std.h

@@ -28,6 +31,16 @@
 #  endif
 #endif

+#if FMT_HAS_INCLUDE(<cxxabi.h>) || defined(__GLIBCXX__)


Why do we need __GLIBCXX__ check? Isn't FMT_HAS_INCLUDE enough?

GCC 4 does not support FMT_HAS_INCLUDE, but it does support demangling.
It is possible to check for the presence of libstdc++ instead of gcc version, since all libstdc++ support demangling.

Could you add a comment that the __GLIBCXX__ is for gcc 4 here then?

vitaut · 2022-09-10T02:24:10Z

include/fmt/std.h

@@ -28,6 +31,16 @@
 #  endif
 #endif

+#if FMT_HAS_INCLUDE(<cxxabi.h>) || defined(__GLIBCXX__)
+#  include <cxxabi.h>
+#  ifndef __GABIXX_CXXABI_H__


What is __GABIXX_CXXABI_H__ check for?

For Android.
See comment from Boost:

// For some archtectures (mips, mips64, x86, x86_64) cxxabi.h in Android NDK is implemented by gabi++ library
// (https://android.googlesource.com/platform/ndk/+/master/sources/cxx-stl/gabi++/), which does not implement
// abi::__cxa_demangle(). We detect this implementation by checking the include guard here.

https://github.com/boostorg/core/blob/162a4e1d24d1cab4f24cbca9489203d891f352e6/include/boost/core/demangle.hpp#L33-L35

Could you add a comment here too?

Done.
And I renamed FMT_HAS_CXXABI_H to FMT_HAS_ABI_CXA_DEMANGLE.

include/fmt/std.h

Signed-off-by: Vladislav Shchapov <[email protected]>

vitaut · 2022-09-10T15:04:05Z

Thank you!

phprus force-pushed the std-exception-1 branch from b187daf to 1d6ba76 Compare September 3, 2022 08:38

phprus marked this pull request as draft September 3, 2022 08:49

phprus force-pushed the std-exception-1 branch from edb2815 to a47b280 Compare September 3, 2022 09:14

phprus marked this pull request as ready for review September 3, 2022 09:30

vitaut requested changes Sep 4, 2022

View reviewed changes

phprus force-pushed the std-exception-1 branch from a47b280 to d3c6804 Compare September 4, 2022 18:52

phprus force-pushed the std-exception-1 branch from d3c6804 to 93b7d39 Compare September 7, 2022 08:35

phprus force-pushed the std-exception-1 branch from 93b7d39 to 98e342f Compare September 9, 2022 18:16

vitaut reviewed Sep 10, 2022

View reviewed changes

phprus force-pushed the std-exception-1 branch 2 times, most recently from d30bf69 to 3ed02f7 Compare September 10, 2022 13:12

Add class name output to formatter for std::exception

3019938

Signed-off-by: Vladislav Shchapov <[email protected]>

phprus force-pushed the std-exception-1 branch from 3ed02f7 to 3019938 Compare September 10, 2022 14:39

vitaut approved these changes Sep 10, 2022

View reviewed changes

vitaut merged commit 21c2137 into fmtlib:master Sep 10, 2022

Krzmbrzl mentioned this pull request Apr 14, 2023

Support formatting nested exceptions #3385

Closed

msimberg mentioned this pull request Dec 8, 2023

Compilation error with clang in CUDA mode #3740

Closed

robinchrist mentioned this pull request Oct 16, 2024

Exception formatting is undocumented #4203

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add class name output to formatter for std::exception #3076

Add class name output to formatter for std::exception #3076

phprus commented Sep 2, 2022

phprus commented Sep 3, 2022

phprus commented Sep 3, 2022

Baardi commented Sep 3, 2022

vitaut left a comment

vitaut Sep 4, 2022

phprus Sep 4, 2022

phprus Sep 4, 2022

vitaut commented Sep 4, 2022

phprus commented Sep 4, 2022

vitaut commented Sep 6, 2022

phprus commented Sep 7, 2022

phprus commented Sep 7, 2022

Baardi commented Sep 9, 2022 •

edited

Loading

vitaut commented Sep 9, 2022

phprus commented Sep 9, 2022

Baardi commented Sep 9, 2022

phprus commented Sep 9, 2022

vitaut left a comment

vitaut Sep 10, 2022

phprus Sep 10, 2022

vitaut Sep 10, 2022

phprus Sep 10, 2022

vitaut Sep 10, 2022

phprus Sep 10, 2022

vitaut Sep 10, 2022

phprus Sep 10, 2022

vitaut commented Sep 10, 2022

Add class name output to formatter for std::exception #3076

Add class name output to formatter for std::exception #3076

Conversation

phprus commented Sep 2, 2022

phprus commented Sep 3, 2022

phprus commented Sep 3, 2022

Baardi commented Sep 3, 2022

vitaut left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vitaut commented Sep 4, 2022

phprus commented Sep 4, 2022

vitaut commented Sep 6, 2022

phprus commented Sep 7, 2022

phprus commented Sep 7, 2022

Baardi commented Sep 9, 2022 • edited Loading

vitaut commented Sep 9, 2022

phprus commented Sep 9, 2022

Baardi commented Sep 9, 2022

phprus commented Sep 9, 2022

vitaut left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vitaut commented Sep 10, 2022

Baardi commented Sep 9, 2022 •

edited

Loading