Significantly - you don't (typically) catch exceptions in erlang. You plan what to do after some process fails.

If your state is corrupted, you should either restart or try to fix the state. Restarting is often simpler, fixing state may even add more errors.

I did many times. What can you really do when FileReader.close() can throw an exception?

It's good design decision in this case. Consider this:
You call library function A().
Library function A() calls some function B(), but you don't know this (closed source).
Library function B() can throw some error, how can you know it? Either it should be catched in A or declared as thrown in A, so that you know that this exception CAN be thrown from A.

Not only telephony. Also in erlang you can make stateful servers, you just don't have shared state. Instead you send messages about data changes between processes. It's like many people talking and updating their knowledge of some situation.

It's only philosophy. In erlang you CAN catch errors (there is even try ... catch and throw). But typically you are encouraged to write programs so that when something fails, you just restart it. I've recently written a server in java which had errors and null pointer exceptions, but it survived, just logged the errors and restarted connection, so you CAN write something like this in other languages. Erlang just gives you some tools to make this even easier.

That's the philosophy of erlang, "Let it crash". Apparently this leads to some of the most reliable systems. http://www.erlang.org/download/armstrong_thesis_2003.pdf
Apparently OP didn't heard about it, because this is the third way.

Recently Germany installed some plate reading cameras near border with Poland to help looking for stolen cars. It didn't yet catch any stolen car, but did catch two drivers without valid insurance. Your theory is already happening.

Probably it's The Automated Curse Generator.

If it's only one of five, it would be extremely interesting for RPi team they are actively working on solutions for usb problems (there were several found and some corrected already). Could you help them and write your experiences in this thread?

10% is not material? I thought bread was 100% chemicals, like everything else. If you have something which is not 100% chemical, you may be on track to winning 1 million GBP

When you consider "no security whatsoever" as "not a bug" then yes, they are really solid.

Let him who has understanding calculate the number of the beast, for it is the number of a man: His number is 666

"Him who has understanding" - programmers?
"calculate the number of the beast" - programmers.
"for it is the number of a man" - primary key
"His number is 666" - SELECT * FROM PEOPLE WHERE ID=666;

It's probably where those "Everything that can be invented has been invented. Charles H. Duell, Commissioner, U.S. patent office, 1899" quotes are coming from. (Yes, I know it is a myth).

This was answered in Permutation_City by Greg Egan. You just start new simulation.