I just want to know if my token stream managed to reset or not.
Especially that parts of composite streams.
karl
4 jul 2008 kl. 12.13 skrev Michael McCandless:
Karl,
I'm sort of confused by this proposal. What is the driver here? It
seems like the overall goal is to have reset() return a boolean
stating whether it was actually implemented by the subclass of
TokenStream?
Mike
Karl Wettin wrote:
How about depricating
> public void reset() throws IOException {}
and refactor it to allow making sure the stream was reset?
To avoid break backwards compatibillity with extentions of the
TokenStream currently in trunk one could introduce something like
this:
> /**
> * @param requireConfirmedReset
> * @throws ResetException An IOException thrown if parameter
requireReset
> * was set true and the stream could not be reset.
> */
> public void reset(boolean requireConfirmedReset)
> throws IOException, ResetException {
> reset();
> if(requireConfirmedReset) throw new ResetException();
> }
and then depricate this new method at some strategic time to
introduce an exception-less solution like:
> /** @return true if this stream was successfully reset. */
> public boolean reset() throws IOException { return false; }
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
