A few things that have worked for me in the past, or things that I have seen work in the past:
1. Quickly "accept", mentally, that it has failed. If you're the person who wrote the code, there is a chance you are surprised that it could fail so you switch to debug mode. Don't do that, just move on.
2. Keep talking. The show becomes more awkward when there is a large uncomfortable silence. If your demo has a presentation alongside it, then restart your app/whatever and quickly move on to your next talking point.
3. If your audience is technically inclined, sometimes it's fun to just quickly describe what went wrong. It could help you connect with your audience better.
4. Continue with everything else that can still work, and don't bring up what failed! Unless something critical went down, there's a good chance the rest of your system will work. The demo might not be as impressive as you wanted, but it's always better than nothing. Oh and don't retry the same feature again. Seeing it fail twice is worse than seeing it fail once, unless you know that it works on even-numbered runs or something :)
5. Carry a backup of your demo if you can, and switch to that quickly. It always helps to have someone else along who can help you switch quickly if need be. This may not be cost-effective or viable, but it's the best option.
Without seeming flippant, your number one priority should be to make sure it doesn't. The only reliable approach to this (at least with an immature product) is a 100% scripted demo that you have run through multiple times both in your office, and ideally where you are going to do the demo.
Ideally you also want to avoid using any sort of live/ad-hoc data if you can (you can trust that this is when an edge case is going to turn up!).
Script it, run through it multiple times and this will minimize the chances of anything unforseen going wrong. If you are not technical make sure you check off your demo with your technical guys so there's nothing they're uncomfortable with on there.
Make sure you're not demoing on either a dev or a live system if possible. You should have an environment just for demos which no-one else touches. Last thing you want is someone doing a release in the middle of it. Make sure the dev team know there's a demo planned in any case.
That said- inevitably things still go wrong, and most people accept this. Smile, and move on.
When Apple demoes desktop applications, they have multiple computers linked to a keyboard-mouse-monitor switch. If the demo fails on one computer, the presenter can quickly switch to a fresh system. IIRC there some videos that show Jobs doing just this.
If you can't afford redundant systems or it would be unelegant to have them around, make sure to make a video or a bunch of screenshots of the planned demo. One of the most fluid "demos" I have ever seen was just a sequence of screenshots. Because the presenter was pointing out things on the screen and clicking on where he would actually have to click to make the next action happen, it somehow felt more like a demo than a slideshow.
The ones I saw, they do not only do that when a demo fails. Almost every single part of a demo runs on a different machine. That minimizes the risk that your demo, by a series of minute deviations from the script, ends up in uncharted waters (this is especially true in alpha or beta software). It introduces a risk of inconsistencies between scene cuts. Those you can minimize by making sure that the 'scenes' at cut points aren't too complex, and by rehearsing, rehearsing, rehearsing.
An anecdote: I was demoing a game to someone on my iPhone. The game crashed so bad it rebooted the phone (bet you didn't know that was possible.) As the game froze but before it crashed out I immediately began talking to them and made eye contact to shift their focus back to me. Kept on talking and making eye contact so they didn't look at the phone and was able to pretend that it had fallen asleep mid-demo. Hit the home button after it rebooted, entered my passcode, and rebooted the game. Worked the second time and I don't think they noticed the crash.
Well, this is kind of vague, but generally speaking the best approach is neither apologize or joke about it. Just acknowledge it simply and keep moving. Don't go down a rat-hole of trying to fix it on the spot.
The best response is also often a matter of the product demographic/audience and maturity cycle. I would handle a tech demo of a failed pacemaker differently than I would handle a failed demo of a just-announced Instagram competitor.
There's some risk to this, but one option is to use a different path/account that will still demonstrate the functionality to the audience. Of course, there's the chance of having it fail on you again, but if you have a feeling what's causing the issue and know how to work around it, then it might help the perception of your app from "not working at all" to "not fully tested".
If you have a team behind the scenes that can fix it within the presentation time, that might be a good demonstration of your ability to recover from the inevitable issues that will arise.
Always have a backup presentation. Either powerpoint, video or something else that your are comfortable with. I believe that the audience will understand...
1. Quickly "accept", mentally, that it has failed. If you're the person who wrote the code, there is a chance you are surprised that it could fail so you switch to debug mode. Don't do that, just move on.
2. Keep talking. The show becomes more awkward when there is a large uncomfortable silence. If your demo has a presentation alongside it, then restart your app/whatever and quickly move on to your next talking point.
3. If your audience is technically inclined, sometimes it's fun to just quickly describe what went wrong. It could help you connect with your audience better.
4. Continue with everything else that can still work, and don't bring up what failed! Unless something critical went down, there's a good chance the rest of your system will work. The demo might not be as impressive as you wanted, but it's always better than nothing. Oh and don't retry the same feature again. Seeing it fail twice is worse than seeing it fail once, unless you know that it works on even-numbered runs or something :)
5. Carry a backup of your demo if you can, and switch to that quickly. It always helps to have someone else along who can help you switch quickly if need be. This may not be cost-effective or viable, but it's the best option.