How resilient should my web app be? [closed]

Question

Lately, I've found myself in quite a few arguments with my boss about the handling of exceptions within our web app (a c# asp.net MVC application).

Basically the conversations go something like this:

Boss: "There is something wrong with our program, client x's database went down today and everyone is seeing the error page."

Me: "Mostly every page in the application uses the database for something (except the error page), there is no reasonable alternative other than to show the error page."

Boss: "Our application should be more resilient -- the part of the application that don't require database access should still function."

Often, the cases are as extreme as this, but sometimes we run into a case where we are integrating with another service where we can still safely show other portions of the page, or complete the operation, albeit with some annoying code as later portions of code need to later use the results of the operation which may have failed. If there are many points of possible failure this can turn into some extremely unmanageable code.

In general, for a "normal" web application (not mission-critical, etc...) how much time do "good" developers spend trying to make their code resilient enough to handle these kind of situations. My boss seems to think that the code should be able handle almost any situation (can't you just catch an exception?). I don't see how this can be economical when there are many possible points of failure.

Answer 1

I'd leave it to the boss to decide. Tell him an estimate in hours how long it would take to make the app "resilient" and he'll decide if it's worth the investment.

Answer 2

Most apps that I've worked on that are heavily data driven have redirected to a custom error page when the main database (ie the one that powers 99% of the pages) is down. (you do want to be showing them a custom screen though, not just letting them get the server error page)

For external services like hitting an SMTP server or a database that isn't used by much of the rest of the app we'll usually have code around it that just displays on-page feedback if the service/database is down/inaccessible.

Its really up the client/stakeholder though, just determine what they want to have happen when the database is down and do it for them. It'll take time but it shouldn't lead to an unmaintainable app or any other coding horror.

Answer 3

I guess I'd be a little worried that you're losing databases with a frequency that causes this question to arise. Even in non-mission critical apps, if you're losing a DB more than once a week, I'd be seeing what I could do about improving that before I worried about crafting ways out of the issue on the user end of the application.

That being said, my company's best practices include coding so that something such as a DB error will failover gracefully on the user end to a "cannot connect" message in the output rather than a full blown 404 type error. I've found that it really doesn't add more than a few minutes to the coding process, and the value of not angering the user is well worth the "cost"