Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with C++ exceptions

marler8997.github.io

Post reply on HN
Print view View original

111–112 of 112 posts

Re: Problems with C++ exceptions

#111

Post by 1718627440 »

rerdavies wrote: post #106
1718627440 wrote: post #70

Earlier quoted context omitted.

If your error codes leak the implementation details through the whole call stack you are doing it wrong. Each error code describes what fails in terms of it's function call semantics. A layer isn't supposed to just return this upwards, that wouldn't make sense, but to use it to choose it's own error return code, which is in the abstraction domain of it's function interface.

Presumes that an error code provides sufficient context to determine what the actual problem is. It does not. Which is why exceptions carry some form of text error message which may include (for example) the name of the file that could not be opened because permission was denied. Awful stuff.

What data can you encode in an out-of-band return value (exception), that you can't encode in a parameter or in-band return value? An exception isn't a magic data type, there is nothing you couldn't also return as a return value or a parameter.

The filename to be opened is likely passed as a string in an argument, so it IS present in the function interface contract.

Re: Problems with C++ exceptions

#112

Post by rerdavies »

barrkel wrote: post #96
1718627440 wrote: post #70

Earlier quoted context omitted.

If your error codes leak the implementation details through the whole call stack you are doing it wrong. Each error code describes what fails in terms of it's function call semantics. A layer isn't supposed to just return this upwards, that wouldn't make sense, but to use it to choose it's own error return code, which is in the abstraction domain of it's function interface.

So you want to gradually reduce the fidelity of the error message as it makes its way up the stack. That means that the top level handler can at best log a vague message. That in turn means you must log along the way where you have more precise information about the failure, or you risk not having enough information to fix issues. And that in turn means you must have lots of redundant logging, since each point in the…

Or you can use chained error messages.

Unable to create the media database. Failed to upgrade the database from version 3 to version 6. SQL Query failed. Syntax error at column 29 near "wehre". ("SELECT id`Thumbnail from tThumbailIndex wehre idFile=?").

(Messages are pre-pended to inner errors as one progresses up the stack). Yes, a gruesome error message. But it's a gruesome error condition.

I've also used inner exceptions in a large Enterprise product, and was very pleased with the result. (Java has them, .net has them, C++ and Typescript can have them if you want them). At the top level, the error message goes:

   Unable to connect to the media database.

   Failed to upgrade from version 3 to version 6. 

   SQL Query error failed.

   Syntax error at column 6 near 'ndex.

   ("SELECT idI'ndex from T_ThumbnailIndex")
(each successive error message contained in a successive inner exception). The advantage: no need to assemble multiple lines of logged errors from a logfile that end-users really don't want to be digging around in.

A more prosaic and actually end-user-helpful chained message might be:

   Unable to connect to the media database.

   Failed to create the file /var/MediaServer/mediaIndex.db

   Out of disk space.
Post reply on HN