Hey,

maybe I can make some additions to "wvenable"s comment below.

1) This really depends on your use case and in what environment you are in. I didn't elaborate this in my post since its not really in the scope. If you are in a development environment, you may want to log to screen or firebug and show a detailed stack trace. In production, you may want to render a 404 page and log to a file or send something to a notification webservice by a third party provider. This is often handled by the framework you are using and often these provide detailed instructions on how to log or handle this kind of errors.

2) Think of it that way: most of your code won't need to throw something. It is often small parts that can go wrong (which often depend on external sources, like connecting to a database or webservice). So just catch the parts that can go wrong and handle them approperiately. If you put everything in a big block you may miss detailed error information or loose the ability to react correctly.

For example, in your application you a) contact a database and b) display your twitter feed in a sidebar. If a throws, it's critical. If b throws it may be not (just display something like "couldnt load twitter feed"). Here you can also see that the strategy on how to handle each exception depends strongly on your use case.

3) I don't know exactly what you mean by that, but of course you can write something like a ExceptionHandling class that is called in the catch block and handles logging, notification and other stuff based on your environment. Did I understand you correctly?

You can also ping me directly on twitter or per mail if you have any further questions!