On Fri, 12 Dec 2025 at 10:12, 叶易安 via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.