Manually checking for a configuration and throwing an exception is no better than just letting the framework throw the exception if the configuration is missing. You are just duplicating precondition checks which happens inside the framework methods anyway, and it makes you code verbose with no benefit. (Actually you might be removing information by throwing everything as the base Exception class. The exceptions thrown by the framework are typically more specific.)
Edit: This answer seem to be somewhat controversial, so a bit of elaboration: Defensive programming means "prepare for the unexpected" (or "be paranoid") and one of the ways to do that is to make lots of precondition checks. In many cases this is good practice, however as with all practices cost should be weighed against benefits.
For example it does not provide any benefit to throw a "Could not obtain connection from factory" exception, since it doesn't say anything about why the provider couldn't be obtained - and the very next line will throw an exception anyway if the provider is null. So the cost of the precondition check (in development time and code complexity) is not justified.
On the other hand the check to verify that the connection string configuration is present may be justified, since the exception can help tell the developer how to resolve the problem. The null-exception you will get in the next line anyway does not tell the name of the connection string that is missing, so your precondition check does provide some value. If your code is part of a component for example, the value is quite big, since the user of the component might not know which configurations the component requires.
A different interpretation of defensive programming is that you should not just detect error conditions, you should also try to recover from any error or exception that may occur. I don't believe this is a good idea in general.
Basically you should only handle exceptions that you can do something about. Exceptions that you cannot recover from anyway, should just be passed upwards to the top level handler. In a web application the top level handler probably just shows a generic error page. But there is not really much to do in most cases, if the database is off-line or some crucial configuration is missing.
Some cases where that kind of defensive programming makes sense, is if you accept user input, and that input can lead to errors. If for example the user provides an URL as input, and the application tries to fetch something from that URL, then it is quite important that you check that the URL looks correct, and you handle any exception that may result from the request. This allows you to provide valuable feedback to the user.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
