This was already mentioned as a bullet point in the section More Advice on Tests, but it's important enough for me to decide to include it as its own section—even if it's a small one.

Depending on the nature of the application that you are writing, it may be acceptable—maybe even expected—that your application will crash if certain conditions aren't met. In other scenarios, like for mobile apps, it's often expected that exceptions will be handled and the application will recover without side effects.

Resiliency is something that needs to be taken into account at the very start of the project. As we saw in previous chapters, you can easily set exception handlers for coroutines, and it doesn't require much work to validate if Deferred or Job ended with an exception, but if you try to add exception handling after a feature is complete, you will have to heavily modify your code, maybe even rewrite the whole thing. This is because resiliency has to come by design; you need to plan ahead and structure your code in a way that will meet the expected behavior.

If I am too late with this advice and you are already in a situation where you will need to significantly rewrite your application, I can still provide you with some wisdom: before you start making any changes, make sure that you have valuable tests for the things that currently work as expected—that will be your safety net. That way, you will be able to guarantee that a certain amount of functionality has been kept between changes.