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.
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.
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.
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.
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.