lingochamp/FileDownloader · error · NoFieldException

getRetryingTimes

Error message

getRetryingTimes

What it means

MessageSnapshot's base getRetryingTimes() throws NoFieldException because the snapshot class does not carry a 'retrying times' field. Only retry-status snapshots override this method with a meaningful value; accessing it on any other snapshot type is invalid.

Solutions

  1. Guard the call with getStatus() == FileDownloadStatus.retry before reading getRetryingTimes()
  2. Obtain retry counts from BaseDownloadTask (getRetryingTimes on the task) rather than the snapshot
  3. Catch IllegalStateException around the accessor when processing heterogeneous snapshots
  4. Do not construct or probe raw MessageSnapshots yourself; rely on FileDownloaderListener callbacks

Example fix

// before
int times = snapshot.getRetryingTimes();
// after
int times = snapshot.getStatus() == FileDownloadStatus.retry ? snapshot.getRetryingTimes() : 0;
Defensive patterns

Strategy: validation

Validate before calling

if (snapshot.getStatus() != FileDownloadStatus.retry) {
    return 0; // no retrying-times field on this snapshot
}

Type guard

int safeGetRetryingTimes(IMessageSnapshot s) {
    if (s.getStatus() != FileDownloadStatus.retry) return 0;
    try { return s.getRetryingTimes(); } catch (IllegalStateException e) { return 0; }
}

Try / catch

try {
    int times = snapshot.getRetryingTimes();
} catch (IllegalStateException e) {
    // snapshot has no retrying-times field for this status
}

Prevention

When it happens

Trigger: Calling IMessageSnapshot.getRetryingTimes() on a MessageSnapshot that is not a RetryMessageSnapshot (e.g. pending, progress, completed snapshots). Reached via the internal update/handoverMessage message pipeline when code probes retry info generically.

Common situations: Generic message handling code that reads retryingTimes for every status; custom listeners that assume retryingTimes is always populated; version differences where the callback API no longer routes through the snapshot.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of lingochamp/FileDownloader@6237a8cac1 (2026-09-08). Data as JSON: /api/errors/b97d6e0f0968aca4. Report an issue: GitHub.

Appendix: source

Thrown at library/src/main/java/com/liulishuo/filedownloader/message/MessageSnapshot.java:48

    protected boolean isLargeFile;

    MessageSnapshot(int id) {
        this.id = id;
    }

    @Override
    public int getId() {
        return id;
    }

    @Override
    public Throwable getThrowable() {
        throw new NoFieldException("getThrowable", this);
    }

    @Override
    public int getRetryingTimes() {
        throw new NoFieldException("getRetryingTimes", this);
    }

    @Override
    public boolean isResuming() {
        throw new NoFieldException("isResuming", this);
    }

    @Override
    public String getEtag() {
        throw new NoFieldException("getEtag", this);
    }

    @Override
    public long getLargeSofarBytes() {
        throw new NoFieldException("getLargeSofarBytes", this);
    }

    @Override

View on GitHub (pinned to 6237a8cac1)