When you instituted the human reliability tests, you *assured* me there was *no* possibility of such a thing *ever* occurring!
So if you read the first part, you’ll know that one of my favorite movies is Dr. Strangelove. And Dr. Strangelove has some really good lessons for those who are learning to build Salesforce Flows. So to continue on that topic, when I was first learning to build flows, I did not know how to handle those unsightly fault error messages. And with the complicated nature of this particular flow and org, this was a frequent problem. They still give me nightmares when I see that little box pop up. 
Rather than doing away with the flow entirely, you can stop that useless message from popping up for your users and at the same time define who is to receive additional information about the fault. A little birdie has been tweeting recently that in Summer ’18 there you might be able to redirect the flow error messages to a different user rather than it automatically going to the person who activated it. But until then….
You started with planning out what the flow needs to do, then you built it out in the editor. Now it is time to handle those faults. I like to have a screen that displays a friendly message to the user and also then an email that is sent to one or more individuals. So you start by building out the screen and the email. Check out this section of Salesforce Help if you need some assistance building the email. One tip that was imparted on me along the way is to use custom labels any time you are working with things like email addresses or record ids in automation. It is a lot easier to change a value in a custom label than it is in a flow or process builder. Jenwlee explains the perils of hardcoding these values in great detail. You just don’t do it. And you should take it one step further in flows and use a custom label for the email. It will make your life easier when someone leaves or gets promoted. Trust me.
So now that we have built out our fault steps, we need to tie all of the action steps to the send email screen. These are the actions like creating records and submitting records to the approval process. One scenario where you might get faults is if there are required fields on a record and you either don’t have them populated by the flow through a default value or a screen for the user to set the value, the flow will fail. These are things that testing should find, but there are always sneaky ways that users will find to break your hard work. 
Well, I, uh, don’t think it’s quite fair to condemn a whole program because of a single slip-up, sir.
So once you have your fault email connected, you’ll connect your fault email step to the email screen that will display to the user. Now comes the fun part. You get to set out to break your flow. You want it to fail to test that the user gets an informative and useful error message and the person receiving the error email, actually receives it. If you can, the easiest way to test it is going to be to leave out a required value on a record create or update. If that’s not an option, your best bet is to look back at previous fault emails you have received and see what caused them and then attempt to replicate them. And if all else fails, do your best to think like a user. Since 
someone will find a way to break it, it’s just a matter of time before you stumble upon a method of breaking it.
After verifying that it works with one scenario, it is best to try to break it in each step along the way to ensure that you have covered all of your bases with the error handling. You don’t want a pesky unhandled fault to slip through the cracks and make its way into production. So by the time I learned how to handle faults in flows, I had beaten so many errors out of it that it was really difficult to test. But there was a validation rule that I figured out how to violate with the flow. And guess what, on my first try, it failed. The email didn’t send and the user got an unhandled fault. I had to go back in and fix the error handling on my error handling. So even if you handled error has an unhandled error, you can do it. Take a step back, make sure that your email and screen are valid and try again.