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
- Check getStatus() before calling isResuming() — it is only valid on pending/connected/progress snapshots
- Query the download task (BaseDownloadTask / FileDownloader) for resume state instead of the snapshot
- Wrap the accessor in a try-catch for IllegalStateException when iterating all message types
- 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
- Check status (pending/connected/progress) before calling isResuming()
- Query the BaseDownloadTask for resume state instead of the snapshot
- Wrap snapshot accessors in defensive helpers with try-catch
- Avoid inspecting raw MessageSnapshots outside the intended lifecycle
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
- getThrowable
- getRetryingTimes
- getEtag
- fetched length[ ] != content length[ ], range[ , ) offset[…
- listener must not be null!
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);
}
@OverrideView on GitHub (pinned to 6237a8cac1)