3w ago

::errno and ned14's system_code go brrrrrrr

I've always found C++'s "trend" of handling normal or non-exceptional system errors with exceptions lackluster (and I'm being charitable). Overall trimming things down to (basically) passing around a couple integers and telling the user to check their manual is much better, much less error prone, and much more efficient and deterministic.

14 comments

Use an enum class, it's strongly typed but the compiler just treats it as an integer
- Yeah they are quite good and they do basically fall under "just wrap an integer".
- Same, I also like giving this the [[nodiscard]] attribute if I want to make sure that it's not ignored.
  
  -Wunused-result is good practice in general
For fuck's sake people, stop localizing your error messages.
- I have no problem with localizing error messages... I just think an error handler is the absolutelest wrong place to do it. Localize it in the manual. Appendix C page 3, "Spanish / Español". Error routines should print machine-readable information. A couple numbers. Maybe a smiley (or, given the context, frownley).
as long as people are logging pertinent information sure. but I've had the misfortune of working with plenty of programs that return just an error code that means 'something went wrong initialising subsystem X' and left it all to the user to figure out what exactly went wrong, with files and where in those files etc. etc.
At work we literally just went through this yesterday, just with folly::Expected. A new guy joined the team and wanted to propose we update how we handle errors.

14 comments