Re: [lmi] [PATCH] Add undisplayable_exception

[Vadim Zeitlin]

On Thu, 09 Oct 2014 11:38:52 +0000 Greg Chicares <address@hidden> wrote:

GC> >  But if this is not enough, I can think of another, arguably better
GC> > solution: instead of modifying report_exception() to know about this
GC> > exception, could we make report_exception() itself customizable? E.g.
GC> > delegate its work to some function pointer, if it's non-NULL?
GC> 
GC> Just a thought: why not avoid the function pointer (so we never have to
GC> set it, or check whether it has been set), and instead declare, e.g.:
GC>   class wx_test_exception { public: explicit 
wx_test_exception(std::string); };
GC> in a header used only by the GUI-test program, and then implement the
GC> ctor only in a translation unit that's linked only into that program?

 Oh, I just didn't think of that. But yes, we could definitely do it like
this. Then any attempt to press this particular button would result in a
linking error and there would be no way to use wx_test_exception in the
normal program without doing something actively malicious (as opposed to
just being mildly curious).

GC> But I don't mind if you disregard that idea as long as we do this:
GC> 
GC> > This would
GC> > allow to not mention undisplayable_exception in the main program code at
GC> > all and make it local to main_wx_test.cpp and so impossible to throw from
GC> > anywhere else -- and, in any case, the main program would report all
GC> > exceptions, avoiding the problem entirely, as it would use exactly the 
same
GC> > report_exception() as now.
GC> 
GC> Excellent idea. Let's do it that way, keeping the production system
GC> unchanged.

 I don't see any way to keep it 100% unchanged, we would still need to have
this override_report_exception function pointer and provide some way of
setting it. So, from some point of view, this is more brittle as someone
could change override_report_exception in the production code, if they were
so inclined.

 So I'm replying to this email quickly just to say that I'm going to follow
your suggestion above and simply move the constructor implementation to the
testing code, making it impossible to create this exception outside of it.
I'll submit the updated patch as soon as I finish rebuilding and retesting
with it.

GC> Thus, the only remaining patch I need to apply to the production system
GC> is the one for LMI_ASSERT_MESSAGE and LMI_ASSERT_EQUAL (along with your
GC> "trivial patch" below), and then you can send me a vast monolithic
GC> GUI-testing patch and I'll quickly apply that.

 Great, TIA!
VZ