util: Don’t throw in GetTime{Millis,Micros}(). Mark as noexcept. #13382

1. 
   practicalswift commented at 5:23 pm on June 3, 2018: contributor

   • boost::posix_time::ptime(boost::gregorian::date(1970,1,1) throws bad_year, bad_day_of_month, or bad_day_month (derivatives of std::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 for 1970-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 to NodeImpl::appInitMain() where they are unhandled.
   • boost::posix_time::from_time_t(0) is simpler and doesn’t throw.
   • Re-use the result of boost::posix_time::from_time_t(0) like we’re doing in DecodeDumpTime(…).
   • Mark GetTimeMillis() and GetTimeMicros() as noexcept.
2. 
   qmma70 commented at 11:48 pm on June 3, 2018: contributor

   Why not use std::chrono::high_resolution_clock?
3. 
   practicalswift commented at 8:42 pm on June 14, 2018: contributor

   @qmma70 I’m all for removing Boost, but that is something for another PR :-)
4. 
   sipa commented at 11:31 pm on June 14, 2018: member

   utACK bcdf285db285932365fe6cae17ba5a585cd1a17e
5. fanquake requested review from theuni on Jun 17, 2018
6. fanquake added the label Utils/log/libs on Jul 1, 2018
7. 
   DrahtBot commented at 3:16 pm on July 29, 2018: member
8. DrahtBot closed this on Jul 29, 2018

   ---

9. DrahtBot reopened this on Jul 29, 2018

   ---

10. 
    Empact commented at 5:35 pm on August 11, 2018: member

    noexcept doesn’t sit right with me here. https://google.github.io/styleguide/cppguide.html#noexcept https://akrzemi1.wordpress.com/2014/04/24/noexcept-what-for/
11. 
    sipa commented at 5:39 pm on August 11, 2018: member

    @Empact What in particular is an argument against noexcept here?
12. 
    Empact commented at 11:10 pm on August 11, 2018: member

    I guess I’m more wondering: what is the justification for it? If it doesn’t help with significant performance optimizations (ala move) and we don’t expect it to affect the error performance of the method (because we don’t expect it to throw) then why should we apply the treatment? If we should apply it here, should we apply it to most methods? Just a notion.
13. 
    practicalswift commented at 2:10 pm on October 7, 2018: contributor

    @Empact Scott Meyers has this to say about noexcept: http://aristeia.com/EC++11-14/noexcept%202014-03-31.pdf – “Declare noexcept whenever possible” :-)
14. 
    DrahtBot commented at 10:59 am on October 20, 2018: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    No conflicts as of last run.

15. DrahtBot added the label Needs rebase on Nov 5, 2018
16. Don't throw in GetTime{Millis,Micros}(). Mark as noexcept. afc97c731e
17. practicalswift force-pushed on Nov 5, 2018
18. DrahtBot removed the label Needs rebase on Nov 5, 2018
19. 
    ken2812221 commented at 7:14 am on December 2, 2018: contributor

    utACK afc97c731e407f87fae0385aa5c3a729981ca1aa
20. 
    MarcoFalke commented at 8:02 pm on December 3, 2018: member

    Looks like this is made obsolete by something like #9566?
21. 
    practicalswift commented at 8:43 pm on December 3, 2018: contributor

    @MarcoFalke Yes, guess so.

    Perhaps I should close this PR? The interest in making GetTime{Millis,Micros}() noexcept seems to be limited: only @sipa, @ken2812221 and I have expressed interest in getting this in :-)

22. practicalswift closed this on Dec 19, 2018

    ---

23. practicalswift deleted the branch on Apr 10, 2021
24. DrahtBot locked this on Aug 16, 2022

Contributors
practicalswift qmma70 sipa DrahtBot Empact ken2812221 MarcoFalke

Review Requested
theuni

Labels
Utils/log/libs