Roman Kennke wrote:
Hi Anton,
I think both approaches are fine and have more or less the same effect.
The 1st throws the exception a little earlier. If the reasoning is to
notify the implementor that there's something missing, this might be
better because it will pop up even in the smallest HelloWorld example.
But I guess there will be some initial focus setup on any window, so
this is not really an argument. Why do you think the 2nd is preferable?
Just because it leaves the implementor a chance not to do additional
work he probably doesn't want to. Say, if he believes he will live without
focus at all (a custom headless toolkit, or kbd-less devises etc.).
Not very useful, of course, but theoretically possible.
Not really. When we throw an exception from the DummyKFMPeer, then the
application will not come up properly. This is why I started this in the
first place (ok, I got an NPE instead of some other execption, but that
doesn't really matter). My reasoning with the DummyKFMPeer was indeed to
leave this open (yes, some apps can indeed live without focus). It could
be a good idea then to issue a warning only, rather than throwing an
exception from the DummyKFMPeer methods.
Since an absence of good/correct implementation of KFMPeer may cause
some hard to investigate focus problems I'd vote for throwing some
exception, because we do not have another good way to warn a developer.
I personally like an idea to have DummyKFMPeer throwing those
exceptions. But from the other hand, throwing an exception in
initPeer() minimize changes :) So, as a lazy person, I have to say that
this approach even better (both have advantages and disadvantages and so
I choose the shortest one :)
Oleg.
