Re: [lmi] [PATCH] Add undisplayable_exception

[Greg Chicares]

On 2014-10-09 12:18Z, Vadim Zeitlin wrote:
> On Thu, 09 Oct 2014 11:38:52 +0000 Greg Chicares <address@hidden> wrote:

[...elided here is an idea earlier discussed, whereby this exception
would be visible to the production system (i.e., 'lmi_wx_shared.exe'),
but implemented through a function pointer that would be NULL in that
system, and non-NULL only in the GUI-test program; for ease of
reference below, let us call this "option PURPLE"...]

> 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?

Let's call that "option BLUE" to make the discussion below clearer.
This is the option that I strongly favor.

>  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).

Yes, exactly. One would need to include a header that obviously doesn't
belong, and invoke a function that's clearly not meant to be used, and
also alter the makefile to make it link. That's enough obstruction to
block foolishness, and it's beyond anyone's power to block malice.

> 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 intended my comment (the last two lines quoted above) to apply to
option BLUE, which can keep production 100% unchanged. (Actually, I
was thinking of a hybrid--VIOLET, say--which could still use a
function pointer as an implementation detail, but wouldn't declare
that pointer anywhere the production system could see it.) But I fear
it appeared to apply to option PURPLE, leading to your rejoinder:

>  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.

...where I think you're saying that BLUE has this "100% unchanged"
advantage but PURPLE does not. But at first I thought you meant that
the "100% unchanged" advantage is not achievable by any means, so I'm
really glad you replied right away:

>  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.

Will you also move the declaration of class undisplayable_exception
to the testing code (e.g., to some header included only in that code),
so that even its declaration is unknown to the production system?
Then production is indeed "100% unchanged".