Improve errors and error handling

[torkleyy]

So we need

• more error types
• include more information
• allow better handling of them (e.g. improve amethyst_assets::Progress stuff)

There are many locations where such improvements can be made, so I'm gonna set this to easy and ask for help here. Small PRs are preferred here.

[torkleyy]

If there are any questions, I'll gladly assist you!

[minecrawler]

What about logging?

[torkleyy]

We also need logging, should be a separate issue though.

[torkleyy]

I'd suggest to use error_chain for this.

[Rhuagh]

YES!

[torkleyy]

So I'm working on better error handling in the assets crate now.

[torkleyy]

I solved the harder part of this in #464 which introduces much better errors for asset handling. What is left are easier jobs for the other crates:

• amethyst_gltf
• amethyst_renderer
• amethyst

All this crates would benefit from using error_chain!.

[Binero]

This issue is strongly tied to #301.

[Aceeri]

Thoughts on using failure for this?

[Binero]

What are the advantages of said crate? It says it tries to solve a lot of problems quick-error and error-chain have, but doesn't go into more detail.

[Hittherhod]

From listening to a talk about failure it seems like error-chain encourages things like a single unified error type for a library as well as having a steep learning curve for newcomers (macros given pretty bad error messages if you mess them up).

[zakarumych]

@Hittherhod. From my experience you easily can define multiple error_chains in crate and establish links between them to use ?. Or use chain_err function to stack up errors for better context of what went bad where you handle errors.

[Rhuagh]

I'm in favor of moving to failure myself.

[Binero]

One major setback in using the failure crate is that it's very hard to maintain type information about the errors you're returning, when there is a series of possible errors. This is especially painful when some error variants are from external libraries, as as far as I know there is no way to implement foreign errors like in error-chain.

Furthermore, much like in error chain, I don't think there is an easy way to chain errors without losing type information.

[AnneKitsune]

for reference https://github.com/rust-lang-nursery/failure

Where do we go from here? failure vs error_chain vs ??

[OvermindDL1]

For note:
rust-lang-deprecated/failure#181

[anderejd]

Where do we go from here? failure vs error_chain vs ??

It doesn't need to be a library, we can use the standard built-in error handling in rust, using .map_err and From impls. This is my preference.

[OvermindDL1]

Even if Failure is used it is still recommended to make your own error enum and don't use the generic Error as that one is designed only for generic setup and testing, not for actual publication. The rest of the stuff in Failure is still very useful.

[distransient]

While working through dealing with some of the unwrap's on my own branch, I found some of the error types to be strange (like PrefabError being a re-export of the Specs error type). I did some looking at Failure and with how complicated of a system Amethyst is, it definitely seems like it'd benefit from how clean the api is for that. I could start working on implementing this for parts of the API like amethyst_animation if people would still like for this to be the way forward.

[distransient]

Actually, it appears that we should probably wait for the work and effects of RFC 2504 (rust-lang/rust#53487) to settle, since it'll likely effect the api of Failure and best path forward generally. Although it's regardless error-chain will be deprecated, it'd still make our lives easier to wait just a little longer on changing our Error strategy 😛

[torkleyy]

This issue is no longer of value. We have an error strategy by now.