lingochamp/FileDownloader · error · NoFieldException

getThrowable

Error message

getThrowable

What it means

MessageSnapshot's base implementations throw NoFieldException (an IllegalStateException) from getThrowable() to signal that this particular snapshot type does not carry a 'throwable' field. Only error-status snapshots override getThrowable() with a real value; calling it on any other snapshot type is an invalid access.

Solutions

  1. Only call getThrowable() after verifying getStatus() == FileDownloadStatus.error
  2. Use the cause delivered through your FileDownloadListener callback (BaseDownloadTask.getCause / errorCallback) instead of probing the snapshot
  3. If you must handle all snapshot types generically, catch IllegalStateException around the accessor
  4. Update to a FileDownloader version where IMessageSnapshot exposes null-safe accessors

Example fix

// before
Throwable t = snapshot.getThrowable();
// after
if (snapshot.getStatus() == FileDownloadStatus.error) {
    Throwable t = snapshot.getThrowable();
}
Defensive patterns

Strategy: validation

Validate before calling

if (snapshot.getStatus() != FileDownloadStatus.error) {
    return null; // no throwable on this snapshot
}

Type guard

Throwable safeGetThrowable(IMessageSnapshot s) {
    if (s.getStatus() != FileDownloadStatus.error) return null;
    try { return s.getThrowable(); } catch (IllegalStateException e) { return null; }
}

Try / catch

try {
    Throwable t = snapshot.getThrowable();
} catch (IllegalStateException e) {
    // snapshot has no throwable field for this status
}

Prevention

When it happens

Trigger: Calling IMessageSnapshot.getThrowable() on a MessageSnapshot whose concrete class does not override getThrowable() — e.g. a pending/progress/started/completed snapshot. Callers are the internal update and handoverMessage paths that inspect snapshots crossing process/service boundaries.

Common situations: A FileDownloaderListener / callback inspects the raw snapshot without first checking getStatus() == error; code written against a different FileDownloader version where the method always returned a value; process-restore (Parcel) produced a snapshot type that doesn't match the expected status.

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

Appendix: source

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

/**
 * The message snapshot.
 */
public abstract class MessageSnapshot implements IMessageSnapshot, Parcelable {
    private final int id;
    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

View on GitHub (pinned to 6237a8cac1)