Simplify error handling?

[Daniel Lee]

Bob and I were discussing this earlier today. Does anyone see a reason to keep the boost error handling framework in our library? So far, we've made allowed our distribution functions to have policy arguments, which is a bit if over-engineering. In order to implement the pattern provided by boost, we've also had to implement a lot of their base exception generating code, but with two template parameters instead of one. If we got rid of it, we would drop half the function signatures and we would have finer control of the error messages. If we ever need policies, we could reimplement them in the future.

Thoughts?

[Marcus Brubaker]

I don't see a reason to keep it and it certainly would simplify a lot of code.  That said, I know very little about what benefits the boost error handling framework potentially provides, even if we're not using it now.

Cheers,
Marcus

On Fri, Oct 19, 2012 at 2:12 AM, Daniel Lee <bea...@alum.mit.edu> wrote:

Bob and I were discussing this earlier today. Does anyone see a reason to keep the boost error handling framework in our library? So far, we've made allowed our distribution functions to have policy arguments, which is a bit if over-engineering. In order to implement the pattern provided by boost, we've also had to implement a lot of their base exception generating code, but with two template parameters instead of one. If we got rid of it, we would drop half the function signatures and we would have finer control of the error messages. If we ever need policies, we could reimplement them in the future.

Thoughts?

--