Error handling in atomic_lib - specify and limit error types

[joepio]

Current error is a dyn Box, which means it's impossible to expect what kind of error will be emitted. Let's limit with some Enum error type.

[joepio]

Types of errors probably look a lot like http errors, since it uses a lot of web concepts

• Authorization (401): incorrect rights / signature
• Not found (404): (part of) resource could not be resolved
• Internal error (500)

[joepio]

AppError in Atomic-Server is pretty bad. It has some unused fields, unnecessary logic. Feels very unfinished. But perhaps it's better to fix that after fixing Atomic-Lib errors, since that's where pretty much all server errors will be coming from.

[joepio]

Current errors are often too verbose, and I don't have a decent strategy of solving this. Example:

 Failed setting propval for 'https://example.com/birthDate' because property 'https://atomicdata.dev/datatypes/Datatype' could not be found. Failed getting property https://atomicdata.dev/datatypes/Datatype. Could not fetch url 'https://atomicdata.dev/datatypes/Datatype'. Status: 500 

I currently use map_err + format! a lot to create long chained strings of errors. This is better than throwing information away, but I need a strategy to keep the messages shorter.

[joepio]

Also, I'd like to standardize these Errors even higher. Maybe introduce an Error class, and maybe give Error types resolvable, persistent IDs. At least I want front-end apps to be more aware of error types. Authentication errors might render a different component, etc.

[joepio]

I think We'll need Error Resources, which can be properly parsed and shown in the front-end. Maybe this will need to be a new Error type. Or maybe all we need is a different handler in server. Not sure what's the best approach here.

[joepio]

We now really need accurate status codes, because the front-end needs to know why requests have failed (authorization => retry when there's a new agent signed in).