When a recoverable error occurs in an app, should the service immediately break with an error or should it continue to function?<p>Example scenario: SQL query returns data different than what the query types says it will.<p>We know this because we validate all data at runtime.<p><pre><code> const userAccount = await pool.one(sql.type(
z.object({
id: z.number(),
firstName: z.string(),
lastName: z.string(),
postHogId: z.string(),
})
)`
SELECT
id,
first_name,
last_name
FROM user_account
`);
</code></pre>
(In this example, this types say that we are expecting `postHogId`, but the query does not return that data.)<p>If we swallow the error (and report it in the background), user _might_ still be able to complete their journey. That is b/c just because types do not match, it does not 100% guarantee that the rest of the app will break.<p>The trade-off is that if we allow unexpected data to flow, it might corrupt the data further down the line. Very hard to recover if this happens at scale. Could also result in pretty gruesome outcomes if query involves financial data.<p>Which strategy does your application take?
Moving from Twitter over to here now:<p>I've had to work through several issues like this in my career. I think there are really a few options, but none of them are great.<p>1. Depending on the error, what data is missing, can you fill in defaults? If its possible to handle this error in a way that doesn't compound into the application crashing, then that would be the best. The fact you have postHogId, means to me that most likely its a critical field that can't be missing, if thats the case then this option won't work.
2. The problem with showing the user the error, is that they can't do anything about it really. But that is an option, let the user know a critical error has occurred and have them restart (again depends on the context). If you can't minimize the blast radius this is the only option IMO. Its so costly when issues compound and cause issues well into the future, and it takes forever to really track down what caused it.
3. What I would do personally is have to understand the real context of where this would occur. I've found that most errors can be handled and hidden from the user, but there are times like you said where someone changed database schema that no matter what you do its not gonna work. It would depend on what depends on the success of this call for example, if this is only one portion of functionality vs a very dependent piece of functionality.<p>Tough situation though, and really there is no right choice, its looking at probability of occurrence, and making decisions based on cost, maintenance, impact to users etc.
There are different kinds of error.<p>There are some errors which aren't the fault of your code (say a timeout or a network connection not working) and it makes sense in cases like that to bend not break.<p>In the case above it is really is your fault that the error is happening and you should fix it as soon as possible.
For "things that should not happen" and that might indeed propagate yuck further into the system, I prefer a brittle approach to stop THAT path ASAP and log it well and get it fixed.<p>Maybe allow other unrelated things to continue per "make -k" though, since we'd probably like to get as much as possible done anyway, safely.