Here's an example of how I've instrumented code in the past. The main focus of this logic is to provide peer-to-peer services for the BadBlue software. The server can listen for connection requests, which can come in either of two formats: HTTP or Gnutella. HTTP requests are dispatched to web services processing, not covered here.
Gnutella protocol requests are dispatched to, among other places, the snippet of code, below. Each request operates in its own thread (this is Win32, which uses a threading model - not the forked process model of Unix/Linux). Multiple threads are thus connected to multiple peers, simultaneously, all exchanging messages, relaying query results, performing discoveries, etc.
The net result can be a system of some complexity. In order to debug this code -- and to get a glimpse into activities of a running production box -- a tunable logging system was added.
The beginning of the snippet notes that we are initializing, with a logging level of 7. This means that if the administrator has "turned up the instrumentation dial" to 7 or above, this message will be sent to the system log.
A little bit further down, we report errors: a bad port number (logging level of 7, we really don't care too much during normal operations) and an attempt to connect to a restricted IP address (which we always want to report as a noteworthy error).
Note that rather than throwing exceptions, the code breaks out. This enables us to dispense with the overhead of exception processing and provide inline instrumentation of any noteworthy events and errors. But exceptions could be thrown just as easily once the instrumentation has done its job. In C++, there appears to be some overhead for using exceptions (and they're forbidden in certain types of real-time or mission-critical systems), so I trap for miscellaneous exceptions - but don't rely upon them for normal error-handling activities.
The log method, below, provides tunable logging consistent with what I've already described.
I suppose the key point here is not whether you're returning error-codes or throwing exceptions; it is, instead, to have sufficient discipline to provide paranoid levels of error-checking and instrumentation so that you can always determine what kinds of things are happening in your code. Even if you think things are hunky-dory.
// beginning of snippet...