Error handling in atomic_lib - specify and limit error types about atomic-server HOT 6 CLOSED

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)

from atomic-server.

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.

from atomic-server.

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.

from atomic-server.

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.

from atomic-server.

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.

from atomic-server.

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).

from atomic-server.