Emil Dotchevski wrote:
<snip> No, not my point. It's about increasing the expressiveness of client code: It provides means for a user to express: "I'm going to throw a bunch of exceptions (starting) with common attributes. Please give me a brief way to create them, so error reporting doesn't obscure my code."
It also allows to easily port "traditional" exception classes to boost::exception.
Further it would allow to allocate the attributes of a custom_exception in one shot.
Yes, I think I understand your point, but...
<snip>
So now you're bringing up a different use case.
... I'm bringing up the different use case because -- at least in my experience -- it is very common when using boost::exception; I'm trying to convince the audience that the effort to bundle multiple pieces of data together perhaps isn't as beneficial as one hopes, because a lot of times all you have is a single piece of data that is relevant to a failure.
I agree. But that use case will become even nicer if you don't have to throw the boost::exceptionS yourself as it's done by the components you use, won't it? As you expressed you'd like boost::exception to become THE exception class, I think you should make it as flexible and inviting to use as possible: There is a whole bunch of existing (and stable) code that uses traditional exception classes. Providing means for a smooth transition will probably increase your library's acceptance. Same goes for avoiding boilerplate code and overhead compared to the traditional approach. Please note that my primary intent is not to sell features. I'm basically just repeating a (subjectively useful) suggestion from a reviewer so it does not get wiped off the table before it has been thoroughly investigated. Regards, Tobias Schwinger - Review Manager -