Re:My most common code review suggestions
by TeMPOraL on Thursday December 07, 2017 @07:44AM
(#15869531)
> but if you must fail, do it as soon and as noisily as possible.
So basically, spam on stderr and abort(). This is not exactly better than exceptions.
> the exception paradigm requires the intimate knowledge of the software to interpret, as it normally vomits a call stack trace. But in production, to the user of the application or the poor system administrator, or even to the programmer who isn’t intimately familiar with the software, that information is nothing but retching vomit, often with no clues as to what went wrong where!
Again, it's printing stuff to stderr, or having the exception system print stuff plus stack trace to stderr. The latter is strictly better than the former. It gives you more clue than printing what would otherwise be an exception message to stderr and aborting on the spot.
And using exceptions do not preclude you from being able to "repair what you can". In fact, it can help it.
I don't like exception abuse either, but it's still better than the C way.
So basically, spam on stderr and abort(). This is not exactly better than exceptions.
> the exception paradigm requires the intimate knowledge of the software to interpret, as it normally vomits a call stack trace. But in production, to the user of the application or the poor system administrator, or even to the programmer who isn’t intimately familiar with the software, that information is nothing but retching vomit, often with no clues as to what went wrong where!
Again, it's printing stuff to stderr, or having the exception system print stuff plus stack trace to stderr. The latter is strictly better than the former. It gives you more clue than printing what would otherwise be an exception message to stderr and aborting on the spot.
And using exceptions do not preclude you from being able to "repair what you can". In fact, it can help it.
I don't like exception abuse either, but it's still better than the C way.