The center for all discussion and news regarding C++.
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.
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
I'm mixed on this one, because sometimes you'll want to call a function for its side effects without caring about the return value. E. g. container methods returning an iterator that shows you where the side effect took place.
Right, so just cast the returned value to void: (void)function();
The new C++ way is
std::ignore = function();
Neat, I learned something. I keep smashing C and C++ together on my head.
The notes on that page do suggest the same method I did, however.
First: it's not new, it's been around since C++03.
Second... it's not even that great. It's more characters to type and you have to deal with stds and colons. (void) is a classic and works everywhere.
But hey, at least it's not static_cast<void>(...).
Cool, I didn't know that was a thing 👍
telling the user to check their manual
QSqlError in my functions and point the user to QSqlError documentation in Qt
F1 at any time in Qt Creator to get the help pagebool return value (I am sitting 10m away in the same room as the client. Senior management is in another state)F1 on their computer and show the user bool QSqlError::isValid()
bool result.
isValid() in an if statement.bool
deleteDocument function is deleting the document but returning false.API::deleteDocument(docId);
if (API::deleteDocument(docId))
{
// output to UI
}
Yes, they called deleteDocument on the same ID twice.
BTW, I did create a manual with usage examples.
A few months later, a senior engineer on the client side checks their code and tells me to throw exceptions for everything, because half of the time, the user-devs are not checking the QSqlError return values.
[[nodiscard]]
From what I remember, that gives a warning an not an error.
The clients' code already has >400 warnings^[edit: fixed wrong word] on every build.
They won't care
Yeah, [[nodiscard]] throws a warning (that's half the point of attributes, anyway).
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.