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.


QSqlErrorin my functions and point the user toQSqlErrordocumentation in QtF1at any time in Qt Creator to get the help pageboolreturn value (I am sitting 10m away in the same room as the client. Senior management is in another state)F1on their computer and show the userbool QSqlError::isValid()boolresult.isValid()in anifstatement.booldeleteDocumentfunction is deleting the document but returning false.API::deleteDocument(docId); if (API::deleteDocument(docId)) { // output to UI }Yes, they called
deleteDocumenton 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
throwexceptions for everything, because half of the time, the user-devs are not checking theQSqlErrorreturn values.From what I remember, that gives a warning an not an error.
The clients’ code already has >400 warnings[1] on every build. They won’t care
edit: fixed wrong word ↩︎
Yeah,
[[nodiscard]]throws a warning (that’s half the point of attributes, anyway).