Thanks for the comments!
Indeed the first version I wrote followed the pattern you suggest (let's
name it pattern_1 for the discussion). However with pattern_1 I could not
cover the case of a method originally not throwing an exception. The
problem is that in pattern_1 we have to catch the exception before deciding
whether to wait or not. But if the decision is not to wait, the caught
exception must be thrown, - which is not allowed by the original method
signature.
That's why I made waitAgain() to (1) not wait in the first call, and (2)
return true iff another call to waitAgain() is anticipated.
This allows to use the same code pattern for both types of methods: those
originally throwing an exception and method originally not throwing. I see
this as an advantage.
As for passing the exception in waitAgain args - this served two purposes:
(1) debugging: it is a convenient single spot in the code to collect info
on the exception that caused the retry, and also on the number of
successive retries for the same original method call. (2) exception
analysis - if one wants to analyze the exception root cause message for
deciding if to wait or not, this is convenient location (although this
would not allow to decide if to retry or not - because even if waitMore
returns false there would be an additional try). So, when the debug is
commented out it is possible to not pass the exception, and also to make
trialsSoFar a boolean - but for debug purposes I would rather leave them
there, I believe there is no real harm done here, particularly because this
method is hardly ever called. Perhaps should mention in the waitMore
javadoc that these args are for debug mainly?
Chris Hostetter <[EMAIL PROTECTED]> wrote on 21/09/2006 12:10:56:
>
> The recurring pattern seems to be...
>
> ResultType methodName(ArgType args) throws ExceptionType {
> int trialsSoFar = 0;
> long maxTime = System.currentTimeMillis() + maxTotalDelay;
> Exception error = null;
> while (waitAgain(maxTime, trialsSoFar++, error)) {
> try {
> return super.methodName(args);
> } catch (ExceptionType e) {
> error = e;
> }
> }
> return super.methodName(args);
> }
>
> ...where the waitAgain method seems to take in more args then it really
> needs (error is completley unused, and trialsSoFar is only need to know
if
> we are on the first trial)
>
> There may be a subltety i'm missing here, but it seems like this might be
> more clearly (and susinctly) expressed with something like...
>
> ResultType methodName(ArgType args) throws ExceptionType {
> long maxTime = System.currentTimeMillis() + maxTotalDelay;
> while (true) {
> try {
> return super.methodName(args);
> } catch (ExceptionType e) {
> if (maxTime < System.currentTimeMillis()) throw e
> }
> wait(maxTime);
> }
> }
>
> ...where the wait method also get's simpler...
>
> static void wait(long maxTime)
> long moreTime = maxTime - System.currentTimeMillis();
> long delay = Math.min(moreTime, intervalDelay);
> try {
> Thread.sleep(delay);
> } catch (InterruptedException e1) { /* NOOP */ }
> }
>
> ...but i haven't tried this, and as i said: there may be some subltety of
> your approach that i'm missing.
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> 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]
