lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <>
Subject Re: [jira] Updated: (LUCENE-665) temporary file access denied on Windows
Date Sun, 24 Sep 2006 05:52:18 GMT
Chris Hostetter <> wrote on 22/09/2006 18:27:40:

> : Indeed the first version I wrote followed the pattern you suggest
> : name it pattern_1 for the discussion). However with pattern_1 I could
> : 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
> : 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.
> Hmmm...  you're refering to methods like "filedExists" and "fileLength"
> right? ... if the method isn't declared to throw the ExceptionType, then
> the only way it can ever arrise from the is if it's a runtime
> exception, in which case the pattern still holds...
>    ResultType methodName(ArgType args) {
>      long maxTime = System.currentTimeMillis() + maxTotalDelay;
>      while (true) {
>        try {
>          return super.methodName(args);
>        } catch (RuntimeException e) {
>          if (maxTime < System.currentTimeMillis()) throw e
>        }
>        wait(maxTime);
>      }
>    }
> ...right?

This assumes JRE methods without IOException in their signature would not
throw IOException, and methods with no Exception in there signature would
not throw anything but RuntimeExceptions. I preferred not to assume this,
specially because of dealing with these unexpected errors. Do you think
this is too protective? If so, a runtime exception can be caught and thrown
in these cases.

I now think there's a better option - still catch Exception in those
methods (cover the unexpected), but throw a RuntimeException that wraps
this exception. The code would be more readable - what do you think?

I think I would also add bound check on number of retries to avoid issues
with clock changes (mentioned recently in another thread). So there would
be two exit criteria - time passed (as now), and too many tries.

> : method is hardly ever called. Perhaps should mention in the waitMore
> : javadoc that these args are for debug mainly?
> if that's the indent then yeah, i would document it.

Will add that.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message