Unify error handling

[etr2460]

We're individually handling errors in a bunch of different components in different ways (are the errors of type string? any? unknown? Error?) and rendering errors in multiple ways (string with the error message, generic error message when hasError is true).

Let's standardize this everywhere and build some helpers for all the components (and new components) to use.

[with-heart]

This is where having a triage person on the team would be helpful by collecting examples of the various ways we're handling errors throughout the codebase in this thread. That would help us make an informed decision!

Pressed for time at the moment but if I get back around to this I'll try to collect those. Would love for someone else to step in and give it a try though! ❤️

[revmischa]

I'd like to lay out a proposal, feel free to suggest other ideas.

We can create a simple base Web3UiError class extending error that is thrown whenever an error is raised. We could have a Web3UiErrorBoundary component that users could wrap their component tree in that catches Web3UiError errors and perhaps does some sort of "toast" action.
We could have an optional property on the error class that says if it's info/warning/error.

N.B. that if we want to check if an error is a Web3UiError instance or not in the ErrorBoundary we need to add one Object.setPrototypeOf call in the base class to make instanceOf work: https://github.com/Microsoft/TypeScript-wiki/blob/main/Breaking-Changes.md#extending-built-ins-like-error-array-and-map-may-no-longer-work

I am happy to implement this if others feel this is the best approach. Or any other approach.

[Dhaiwat10]

@etr2460 @with-heart @crondinini would love to hear your opinions on the approach suggested by @revmischa!

I'm mostly a student in this department so I'm gonna learn from the sidelines 😄

[e-roy]

closing because of massive structure change