Use an enum class, it's strongly typed but the compiler just treats it as an integer
post
telling the user to check their manual
- So I made an API for a DB.
- The client was full on using Qt Framework with Qt Creator, so I also made it in Qt.
- I return
QSqlErrorin my functions and point the user toQSqlErrordocumentation in Qt- I even show them that they can press
F1at any time in Qt Creator to get the help page
- I even show them that they can press
- Months later, client engineers raise problem with senior management that they don't have a
boolreturn value (I am sitting 10m away in the same room as the client. Senior management is in another state) - I press
F1on their computer and show the userbool QSqlError::isValid()- Note again, that all client devs at this point, have been using Qt, years before I enter.
- User says they don't have a
boolresult.- I open their code and show them how to use
isValid()in anifstatement.
- I open their code and show them how to use
- User puts a requirement for custom functions returning
bool- I make more functions for that
- Months later, I get a bug report, stating that the
deleteDocumentfunction is deleting the document but returning false. - I check the code
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
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.
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).
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.
all 16 comments