On Mon, Oct 20, 2008 at 12:33 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> This fix doesn't structurally seem quite right, and the comment is
> incorrect: the re-parse happens when the remote site is in but returns bad
> content.
>
> One fundamental issue here is that there's no disambiguation between cause
> of GadgetException: parse error vs. fetch exception vs. fetch non-OK
> status.
> In lieu of exception refactoring, it seems to me that it would be best to
> put this code in fetchObjectAndCache(...) eg:
That's actually a good thing. We don't want to waste time going back to the
network when we know the last check was in error (for any reason). The only
time that this becomes an issue is if your min ttl is excessively high.
>
> GadgetSpec spec = null;
> try {
> spec = new GadgetSpec(url, response.getResponseAsString());
> } catch (GadgetException e) {
> // poor form in a method that throws a GadgetException itself maybe, but
> boxes in parsing logic
> // generate error spec
> }
>
> // ...code goes on to (negative) cache the spec as it should.
>
> Reintroduction of negative caching on GadgetExceptions caused in the other
> noted ways is of course very important.
>
