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
- Guard the call with getStatus() == FileDownloadStatus.retry before reading getRetryingTimes()
- Obtain retry counts from BaseDownloadTask (getRetryingTimes on the task) rather than the snapshot
- Catch IllegalStateException around the accessor when processing heterogeneous snapshots
- 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
- Only call getRetryingTimes() on retry-status snapshots
- Get retry counts from BaseDownloadTask rather than message snapshots
- Guard every snapshot accessor with a status check
- Treat NoFieldException (IllegalStateException) as a signal of wrong-status access
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
- getThrowable
- isResuming
- 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/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);
}
@OverrideView on GitHub (pinned to 6237a8cac1)