Adding Results to Bevy

[zenMaya]

Right now bevy does not handle errors in any way. There is no Result returning done anywhere. There should be an Enum of possible errors that can be use as errors in bevy internals and to report errors that aren't explicitly from Rust but from bevy's runtime errors that are non-panicking (like locking the cursor)

[haselkern]

I like how ggez handles this. Every method returns a Result, so that you can always use the ? operator to bubble the error up until you can handle it.

[zenMaya]

only problem is, that bevy is inherently multi-threaded, so results won't do us any good from blocking threads. Should we use some kind of global event system?

[Fishrock123]

only problem is, that bevy is inherently multi-threaded, so results won't do us any good from blocking threads.

Do you mean asynchronous operations from the main thread? Perhaps there should be functions which return futures for such situations in addition to _sync ones?

[zenMaya]

what I mean is that there are loop functions, like Winit loop that should not return result at all and should instead announce that error occured

[cart]

There is no Result returning done anywhere

This is hyperbole. We certainly use results in a number of places, but I agree that there is a lot of room for improvement here. Reducing the number of panics is definitely a part of our plan.

I think adding Result Systems (#25) is the long term solution to this problem. Even if all internal bevy apis return Results, if systems don't support them then they need to panic when they encounter errors. If systems returned results, we could have a customizable global error handler (see the Result Systems issue for more context).

[zenMaya]

Also something like winit window loop should use channel for errors. It cannot return a result, since it shouldn't panic but cannot return a result.

[alice-i-cecile]

Closing as while this is a good idea, it's not specific enough to be actionable.