Consider this 2 exception outputs.
===== case A =====
terminate called after throwing an instance of 'network_error'
what(): connection failed (104).
===== case B =====
terminate called after throwing an instance of 'network_error'
what(): conection failed (with layer = transport, protocol = tcp, local_endpoint =
0.0.0.0:21798, remote_endpoint =
198.23.64.125:37720, error_code = 104, reason = "Connection reset by peer", status = "SYN ACK")
In user's perspective, the user/caller usually prefers an output like B. But currently almost all C++ 3rd-party libraries (who use exception rather then error_code/assert) provides something like A.
Maybe should we **encourage** people to carry more information in exceptions?
For case B you are much better off capturing the data in the exception object directly, not formatting it as a string.
e.g. std::filesystem::filesystem_error contains two paths and an error_code, which can be extracted individually and formatted in different ways when catching the exception.
If you just squash all that information into the std::string passed to the constructor, users have to parse the string to retrieve it.
So the problem is designing better exception classes that capture important information, not making it easier to squash more information into a string.