Should date::format throw a date::format_error to be more consistent with C++20?
date::format currently throws std::ios_base::failure upon formatting errors. The C++20 spec mandates that a std::format_error be thrown for chrono 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:
try
{
std::cout << date::format("%F", std::chrono::seconds(42));
}
catch (const std::ios_base::failure& e)
{
std::cerr << "Stream failure: " << e.what() << "\n" << std::flush;
}
catch (const date::format_error& e)
{
std::cerr << "Formatting error: " << e.what() << "\n";
}
If my proposed date::format_error derives from std::ios_base::failure, then existing applications catching an std::ios_base::failure should still work. Since std::ios_base::failure derives from std::runtime_error, date::format_error would also be consistent with std::format_error deriving from std::runtime_error (i.e. catching std::runtime_error would catch both std::format_error and date::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.
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:
- Much closer compatibility with C++20.
- Superior formatting facilities.
Cons to adopting fmt:
- More work that I haven't made time to do.
- Instability for existing clients.
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).