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
- Only call getThrowable() after verifying getStatus() == FileDownloadStatus.error
- Use the cause delivered through your FileDownloadListener callback (BaseDownloadTask.getCause / errorCallback) instead of probing the snapshot
- If you must handle all snapshot types generically, catch IllegalStateException around the accessor
- 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
- Check getStatus() == FileDownloadStatus.error before calling getThrowable()
- Prefer listener callbacks that deliver the cause directly
- Handle snapshots by status before accessing non-id/getStatus accessors
- Catch IllegalStateException when writing generic snapshot-processing code
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
- getRetryingTimes
- 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/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);
}
@OverrideView on GitHub (pinned to 6237a8cac1)