util: Don't throw in GetTime{Millis,Micros}(). Mark as noexcept.#13382
util: Don't throw in GetTime{Millis,Micros}(). Mark as noexcept.#13382practicalswift wants to merge 1 commit intobitcoin:masterfrom
Conversation
|
@qmma70 I'm all for removing Boost, but that is something for another PR :-) |
|
utACK bcdf285db285932365fe6cae17ba5a585cd1a17e |
| The last travis run for this pull request was 55 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened. |
|
|
|
@Empact What in particular is an argument against noexcept here? |
|
I guess I'm more wondering: what is the justification for it? If it doesn't help with significant performance optimizations (ala |
|
@Empact Scott Meyers has this to say about |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
practicalswift
force-pushed
the
dont-throw-in-GetTimeMillis-and-GetTimeMicros
branch
from
bcdf285 to
afc97c7
Compare
|
utACK afc97c7 |
|
Looks like this is made obsolete by something like #9566? |
|
@MarcoFalke Yes, guess so. Perhaps I should close this PR? The interest in making |
practicalswift
deleted the
dont-throw-in-GetTimeMillis-and-GetTimeMicros
branch
8 participants
boost::posix_time::ptime(boost::gregorian::date(1970,1,1)throwsbad_year,bad_day_of_month, orbad_day_month(derivatives ofstd::out_of_range) if the year, month or day are out of range. It is obvious to us that it won't throw at run-time for1970-01-01, but that is not obvious for the compiler or static analyzers. From a static analyzer perspective it will look like these exceptions can reach all the way up toNodeImpl::appInitMain()where they are unhandled.boost::posix_time::from_time_t(0)is simpler and doesn't throw.boost::posix_time::from_time_t(0)like we're doing inDecodeDumpTime(…).GetTimeMillis()andGetTimeMicros()asnoexcept.