Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added AssetLoadFailedEvent, UntypedAssetLoadFailedEvent #11369
Added AssetLoadFailedEvent, UntypedAssetLoadFailedEvent #11369
Changes from 3 commits
ae6d118
3a4c0be
8937079
12d9b64
e449b4e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When will this be None?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be totally honest, I can't say I have a firm grasp on that. It maps 1:1 with
InternalAssetEvent::Failed
– which in some cases doesn't have a resolved handle.I'd be okay with dropping this field for the time being. Users can use the asset path to lookup the asset id / handle from the asset server if needed and there's no real reason to keep the handle alive via the event. The handle should be in the world already from the original
load()
if it's useful to retain the asset (and potentially retry).What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current event API only delivers IDs (weak handles), I think the contract is that you are responsible for keeping handles from load requests alive - the event system is not going to do that for you. Unless there's some other circumstances that could arise from handling the error, we should probably follow the same pattern with the error events and keep the actual event as small as possible while still containing all necessary information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think dropping the field makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we able to reasonably derive PartialEq here? If so, please do: it's really useful for writing tests on error types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately not due to the
std::io::Error
in theIo
variantThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this my first impression is that something like an HttpError, which is only relevant for some
AssetReader
s, should only be implemented for those particular readers. However, neitherAssetReader
norAssetWriter
allow defining custom error types likeAssetLoader
andAssetSaver
do.This is probably something that ought to be looked at in the future, but I think it is also outside the scope of this PR, so this is good for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see the case for that. I do think having well-defined variants is useful for allowing downstream code to handle errors however desireable. For example: https://github.com/bevyengine/bevy/pull/11349/files#diff-b21bad69535483663d48f483c940909cef359606f3fc1094508dc25c3ea86327R83-R102:
I'm having a hard time imagining anything other than general
Io
andHttp
errors, but I could be missing something.It wouldn't be the end of the world to end up at what you're suggesting:
If there are generally accepted error types for I/O and HTTP errors, one could use downcasting to get at any low-level information needed. This does seem outside the scope of this PR, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PartialEq on all these error types too please.