On 06/25/2012 02:50 PM, Robert Ramey wrote:
With boost.exception
throw X catch X, add info, rethrow X catch X I didn't really think about this, but now you mention it I'm convinced that my interface is far superior.
For an App using an API this scenario is the most pleasant. It allows the two ways App developers need throw X catch X or the one above. I'm unfocused on how an exception/class's members/properties fill in but at the final catch want it to be complete with exception message and the what-caused-it-from-where-info available. (With only one exception framework to learn and maintain). If another library/API uses boost the App needs the API's to do the filling in where the info is available and the App's code very tight, readable and maintainable. And threads are becoming more involved as hardware starts to go to more and more cpu's. Even areas that weren't often paralleled before will be. (Just can't sit there with 7 or more idle processors nowadays)
I guess this last catch X uses the multiple inheritace of the boost exception object to permit catch X rather than catch boost::exception which syntatically looks clean. But now you've got an interface - catch X which actually is an X++.
It is actually throw X-- catch X--, add info, rethrow X catch X My preference is to not know anything about X-- or learn about and write for Y, Z or W, U and V layers, adders to or representatives of X--. Just want X.