lingochamp/FileDownloader · error · NoFieldException

isResuming

Error message

isResuming

What it means

MessageSnapshot's base isResuming() throws NoFieldException because this snapshot type has no 'resuming' field. Only pending/connected/progress-type snapshots override isResuming() with a real value; calling it on others (started, warn, etc.) is an invalid field access.

Solutions

  1. Check getStatus() before calling isResuming() — it is only valid on pending/connected/progress snapshots
  2. Query the download task (BaseDownloadTask / FileDownloader) for resume state instead of the snapshot
  3. Wrap the accessor in a try-catch for IllegalStateException when iterating all message types
  4. Keep using the listener-callback model rather than inspecting internal snapshots

Example fix

// before
boolean resuming = snapshot.isResuming();
// after
boolean resuming = snapshot.getStatus() == FileDownloadStatus.progress && snapshot.isResuming();
Defensive patterns

Strategy: validation

Validate before calling

boolean statusSupportsResuming(byte status) {
    return status == FileDownloadStatus.pending
        || status == FileDownloadStatus.connected
        || status == FileDownloadStatus.progress;
}

Type guard

boolean safeIsResuming(IMessageSnapshot s) {
    if (!statusSupportsResuming(s.getStatus())) return false;
    try { return s.isResuming(); } catch (IllegalStateException e) { return false; }
}

Try / catch

try {
    boolean resuming = snapshot.isResuming();
} catch (IllegalStateException e) {
    // snapshot type has no resuming field
}

Prevention

When it happens

Trigger: Calling IMessageSnapshot.isResuming() on a MessageSnapshot subclass that does not override it — e.g. StartedMessageSnapshot. Reached from the update/handoverMessage pipeline or from user code probing resume state on an arbitrary snapshot.

Common situations: UI code that renders 'resumed from breakpoint' state for every message without checking status; code migrated from a task-based API where isResuming was always available; snapshots reconstructed from Parcel in a way that changes their type.

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/e026c7ad16514268. Report an issue: GitHub.

Appendix: source

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

    @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
    public long getLargeTotalBytes() {
        throw new NoFieldException("getLargeTotalBytes", this);
    }

    @Override

View on GitHub (pinned to 6237a8cac1)