Open ecorm opened 4 years ago
My proposed date::format_error
could also include more helpful what
messages than the ones currently generated by setting the failbit
on the internal ostringstream
.
Ideally date
should build on https://github.com/fmtlib/fmt . That being said, I don't think a half-way solution would be valuable.
Pros to adopting fmt
:
Cons to adopting fmt
:
With any half-way attempt I'm afraid that the cons would hit without really achieving much of the pros.
Or perhaps it could be the other way around with fmt
adding support for time_point
via the help of your library (to do the date calculations).
date::format
currently throwsstd::ios_base::failure
upon formatting errors. The C++20 spec mandates that astd::format_error
be thrown forchrono
formatting errors (reference).Should
date::format
instead throw a (proposed)date::format_error
, to be more consistent with the standard? This would allow users to catch formatting errors separately from other stream errors:If my proposed
date::format_error
derives fromstd::ios_base::failure
, then existing applications catching anstd::ios_base::failure
should still work. Sincestd::ios_base::failure
derives fromstd::runtime_error
,date::format_error
would also be consistent withstd::format_error
deriving fromstd::runtime_error
(i.e. catchingstd::runtime_error
would catch bothstd::format_error
anddate::format_error
).The lack of
date::format_error
is not a showstopper for me, but I thought it may be something "nice to have" in order to be more consistent with C++20.