Every time I start working with a new client, I need to take time to explain the same topic of handling in-app errors. Why are they important? Why can't you ignore them? Clients don't want to think about the errors because they often associate them with a bad/unwanted thing that shouldn't appear in your app. That couldn't be further from the truth, and errors are a regular thing in your app. They're a part of good design.
Imagine that you lose connection with the internet, which is a typical case, especially if you're traveling a lot. The users would be confused by the infinitely loading screens. Instead, you should think of some popup, snack bar, or even a full-screen page explaining that you have no data connection. The same goes for app-specific errors like premium features in the app that are not available for this user, restrictions on the number of characters in the text field, or limitations of how many GBs of data a single user can store.
Start right away
Don't ignore the problem! Even if you're making an MVP, it should always stay in the back of your head that these errors can occur and that you need to make space for them in the app. I don't mean that you have to implement every error screen immediately, but more that you should acknowledge these errors exist and not sweep them under the rug. Instead, you can handle these errors with some generic messages, toasts, images, etc.
Types of errors
No network error
The most common error in your app is a lack of mobile data. As a result, you cannot make any requests/actions in your app. Usually, the simple way to handle it is to show some toast and a snack bar and retry the request/action whenever your connection comes back.
This error happens when the request takes too long to process. For example, you can get this error when the server doesn't answer within a specific time. You might try to retry sending it again after some time, but this isn't strictly necessary. It's usually better to inform the user that they got timed out and add a button if they want to retry making the request. Alternatively, you could just put some countdown to do this automatically after a few seconds.
When you're unauthorized in the app, this can happen for various reasons, e.g., an expired session, a limited number of devices, after resetting your password on another device, etc. After encountering this error, the user should be logged out and usually moved to the login/welcome page in the app. Apps typically don't inform the user when they suddenly get logged out, but it's good practice to explain why that happened.
Internal server error - 500
You'll receive an error when something goes wrong on the server (for example, an unhandled edge case or a mistake on your backend). Usually, the best way to handle these errors is for you to receive some message from BE or an error code explaining why they occurred. In this way, you can present a proper explanation to the user. Sometimes, however, this is not possible, especially when using 3rd party APIs. In those cases, you could display some generic error message.
Unprocessable entity error
The request was well-formed, but the server was unable to process it. Usually, when you fill in some request data, that is not allowed, or you don't provide a required parameter in the request. A good way of handling such errors is to show which field is incorrect and deliver a message informing why that's the case.
Empty list (no results)
There are simply no results for the request you're making. Maybe you're searching for something, but it doesn't exist, or perhaps you're a fresh user and cannot see anything on the timeline because you haven't yet followed anyone. These are all relevant reasons you could encounter this error, and it's worth communicating to the user what they should do to see the results.
Your account is not authorized to access the requested resource. For example, you might already have logged in, but you may not be on the premium plan, so you don't have access to this feature. An excellent way to handle these errors is to inform the user that they don't have access but then provide a list of the steps they need to take to unlock it.
Any app-specific errors like: you've reached a limit, the file is too big, wrong verification code, etc.
It all depends on the context. There's no one way to handle all these various errors, but don't worry! They're usually the easiest to handle compared to the previous ones because you should know precisely why they're happening. When you already know the context, you should already have an idea of how you can handle them. For example, you could use a simple toast or a snack bar, an error field in the text field, a full-screen error image, or just some red-colored text. It's not a big issue if you think of it ahead.
I hope you now better understand what errors can occur in your app. Now they're not that scary, are they? These are planned and valid responses or failures that can occur for unknown reasons. In either case, it's crucial to handle them correctly to avoid scaring the users.