We Keep Coding

What is the purpose of using the following try-catch block? c# [duplicate]

I'm looking at the article C# - Data Transfer Object on serializable DTOs.
The article includes this piece of code:
public static string SerializeDTO(DTO dto) {
try {
XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
StringWriter sWriter = new StringWriter();
xmlSer.Serialize(sWriter, dto);
return sWriter.ToString();
}
catch(Exception ex) {
throw ex;
}
}
The rest of the article looks sane and reasonable (to a noob), but that try-catch-throw throws a WtfException... Isn't this exactly equivalent to not handling exceptions at all?
Ergo:
public static string SerializeDTO(DTO dto) {
XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
StringWriter sWriter = new StringWriter();
xmlSer.Serialize(sWriter, dto);
return sWriter.ToString();
}
Or am I missing something fundamental about error handling in C#? It's pretty much the same as Java (minus checked exceptions), isn't it? ... That is, they both refined C++.
The Stack Overflow question The difference between re-throwing parameter-less catch and not doing anything? seems to support my contention that try-catch-throw is-a no-op.
EDIT:
Just to summarise for anyone who finds this thread in future...
DO NOT
try {
// Do stuff that might throw an exception
}
catch (Exception e) {
throw e; // This destroys the strack trace information!
}
The stack trace information can be crucial to identifying the root cause of the problem!
DO
try {
// Do stuff that might throw an exception
}
catch (SqlException e) {
// Log it
if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
// Do special cleanup, like maybe closing the "dirty" database connection.
throw; // This preserves the stack trace
}
}
catch (IOException e) {
// Log it
throw;
}
catch (Exception e) {
// Log it
throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
// Normal clean goes here (like closing open files).
}
Catch the more specific exceptions before the less specific ones (just like Java).
References:
MSDN - Exception Handling
MSDN - try-catch (C# Reference)

First, the way that the code in the article does it is evil. throw ex will reset the call stack in the exception to the point where this throw statement is losing the information about where the exception actually was created.
Second, if you just catch and re-throw like that, I see no added value. The code example above would be just as good (or, given the throw ex bit, even better) without the try-catch.
However, there are cases where you might want to catch and rethrow an exception. Logging could be one of them:
try
{
// code that may throw exceptions
}
catch(Exception ex)
{
// add error logging here
throw;
}

Don't do this,
try
{
...
}
catch(Exception ex)
{
throw ex;
}
You'll lose the stack trace information...
Either do,
try { ... }
catch { throw; }
OR
try { ... }
catch (Exception ex)
{
throw new Exception("My Custom Error Message", ex);
}
One of the reason you might want to rethrow is if you're handling different exceptions, for
e.g.
try
{
...
}
catch(SQLException sex)
{
//Do Custom Logging
//Don't throw exception - swallow it here
}
catch(OtherException oex)
{
//Do something else
throw new WrappedException("Other Exception occured");
}
catch
{
System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
throw; //Chuck everything else back up the stack
}

C# (before C# 6) doesn't support CIL "filtered exceptions", which VB does, so in C# 1-5 one reason for re-throwing an exception is that you don't have enough information at the time of catch() to determine whether you wanted to actually catch the exception.
For example, in VB you can do
Try
..
Catch Ex As MyException When Ex.ErrorCode = 123
..
End Try
...which would not handle MyExceptions with different ErrorCode values. In C# prior to v6, you would have to catch and re-throw the MyException if the ErrorCode was not 123:
try
{
...
}
catch(MyException ex)
{
if (ex.ErrorCode != 123) throw;
...
}
Since C# 6.0 you can filter just like with VB:
try
{
// Do stuff
}
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
// Handle, other exceptions will be left alone and bubble up
}

My main reason for having code like:
try
{
//Some code
}
catch (Exception e)
{
throw;
}
is so I can have a breakpoint in the catch, that has an instantiated exception object. I do this a lot while developing/debugging. Of course, the compiler gives me a warning on all the unused e's, and ideally they should be removed before a release build.
They are nice during debugging though.

A valid reason for rethrowing exceptions can be that you want to add information to the exception, or perhaps wrap the original exception in one of your own making:
public static string SerializeDTO(DTO dto) {
try {
XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
StringWriter sWriter = new StringWriter();
xmlSer.Serialize(sWriter, dto);
return sWriter.ToString();
}
catch(Exception ex) {
string message =
String.Format("Something went wrong serializing DTO {0}", DTO);
throw new MyLibraryException(message, ex);
}
}

Isn't this exactly equivalent to not
handling exceptions at all?
Not exactly, it isn't the same. It resets the exception's stacktrace.
Though I agree that this probably is a mistake, and thus an example of bad code.

You don't want to throw ex - as this will lose the call stack. See Exception Handling (MSDN).
And yes, the try...catch is doing nothing useful (apart from lose the call stack - so it's actually worse - unless for some reason you didn't want to expose this information).

This can be useful when your programming functions for a library or dll.
This rethrow structure can be used to purposefully reset the call stack so that instead of seeing the exception thrown from an individual function inside the function, you get the exception from the function itself.
I think this is just used so that the thrown exceptions are cleaner and don't go into the "roots" of the library.

A point that people haven't mentioned is that while .NET languages don't really make a proper distinction, the question of whether one should take action when an exception occurs, and whether one will resolve it, are actually distinct questions. There are many cases where one should take action based upon exceptions one has no hope of resolving, and there are some cases where all that is necessary to "resolve" an exception is to unwind the stack to a certain point--no further action required.
Because of the common wisdom that one should only "catch" things one can "handle", a lot of code which should take action when exceptions occur, doesn't. For example, a lot of code will acquire a lock, put the guarded object "temporarily" into a state which violates its invariants, then put it object into a legitimate state, and then release the lock back before anyone else can see the object. If an exception occurs while the object is in a dangerously-invalid state, common practice is to release the lock with the object still in that state. A much better pattern would be to have an exception that occurs while the object is in a "dangerous" condition expressly invalidate the lock so any future attempt to acquire it will immediately fail. Consistent use of such a pattern would greatly improve the safety of so-called "Pokemon" exception handling, which IMHO gets a bad reputation primarily because of code which allows exceptions to percolate up without taking appropriate action first.
In most .NET languages, the only way for code to take action based upon an exception is to catch it (even though it knows it's not going to resolve the exception), perform the action in question and then re-throw). Another possible approach if code doesn't care about what exception is thrown is to use an ok flag with a try/finally block; set the ok flag to false before the block, and to true before the block exits, and before any return that's within the block. Then, within finally, assume that if ok isn't set, an exception must have occurred. Such an approach is semantically better than a catch/throw, but is ugly and is less maintainable than it should be.

While many of the other answers provide good examples of why you might want to catch an rethrow an exception, no one seems to have mentioned a 'finally' scenario.
An example of this is where you have a method in which you set the cursor (for example to a wait cursor), the method has several exit points (e.g. if () return;) and you want to ensure the cursor is reset at the end of the method.
To do this you can wrap all of the code in a try/catch/finally. In the finally set the cursor back to the right cursor. So that you don't bury any valid exceptions, rethrow it in the catch.
try
{
Cursor.Current = Cursors.WaitCursor;
// Test something
if (testResult) return;
// Do something else
}
catch
{
throw;
}
finally
{
Cursor.Current = Cursors.Default;
}

One possible reason to catch-throw is to disable any exception filters deeper up the stack from filtering down (random old link). But of course, if that was the intention, there would be a comment there saying so.

It depends what you are doing in the catch block, and if you are wanting to pass the error on to the calling code or not.
You might say Catch io.FileNotFoundExeption ex and then use an alternative file path or some such, but still throw the error on.
Also doing Throw instead of Throw Ex allows you to keep the full stack trace. Throw ex restarts the stack trace from the throw statement (I hope that makes sense).

In the example in the code you have posted there is, in fact, no point in catching the exception as there is nothing done on the catch it is just re-thown, in fact it does more harm than good as the call stack is lost.
You would, however catch an exception to do some logic (for example closing sql connection of file lock, or just some logging) in the event of an exception the throw it back to the calling code to deal with. This would be more common in a business layer than front end code as you may want the coder implementing your business layer to handle the exception.
To re-iterate though the There is NO point in catching the exception in the example you posted. DON'T do it like that!

Sorry, but many examples as "improved design" still smell horribly or can be extremely misleading. Having try { } catch { log; throw } is just utterly pointless. Exception logging should be done in central place inside the application. exceptions bubble up the stacktrace anyway, why not log them somewhere up and close to the borders of the system?
Caution should be used when you serialize your context (i.e. DTO in one given example) just into the log message. It can easily contain sensitive information one might not want to reach the hands of all the people who can access the log files. And if you don't add any new information to the exception, I really don't see the point of exception wrapping. Good old Java has some point for that, it requires caller to know what kind of exceptions one should expect then calling the code. Since you don't have this in .NET, wrapping doesn't do any good on at least 80% of the cases I've seen.

In addition to what the others have said, see my answer to a related question which shows that catching and rethrowing is not a no-op (it's in VB, but some of the code could be C# invoked from VB).

Most of answers talking about scenario catch-log-rethrow.
Instead of writing it in your code consider to use AOP, in particular Postsharp.Diagnostic.Toolkit with OnExceptionOptions IncludeParameterValue and
IncludeThisArgument

Rethrowing exceptions via throw is useful when you don't have a particular code to handle current exceptions, or in cases when you have a logic to handle specific error cases but want to skip all others.
Example:
string numberText = "";
try
{
Console.Write("Enter an integer: ");
numberText = Console.ReadLine();
var result = int.Parse(numberText);
Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
if (numberText.ToLowerInvariant() == "nothing")
{
Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}
else
{
throw;
}
}
finally
{
Console.WriteLine("Freed some resources.");
}
Console.ReadKey();
However, there is also another way of doing this, using conditional clauses in catch blocks:
string numberText = "";
try
{
Console.Write("Enter an integer: ");
numberText = Console.ReadLine();
var result = int.Parse(numberText);
Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}
finally
{
Console.WriteLine("Freed some resources.");
}
Console.ReadKey();
This mechanism is more efficient than re-throwing an exception because
of the .NET runtime doesn’t have to rebuild the exception object
before re-throwing it.

try catch block or boolean flag?

I'm not sure about my code, I want to save first into Blob Azure and if it was successful then save that url into my database, I have two ways to do this. The first one using a boolean variable named flag, if flag value is set to true then I can save it into my database, but I'm not sure if this code is the best approach. Is it possible that for some reason the file is not uploaded to Blob and even if that happens flag value is set to true?:
First approach using boolean flag variable :
using (Stream fileStream = file.InputStream)
{
blockBlob.UploadFromStream(fileStream);
flag = true;
}
if (flag == true)
{
Urls.Add(blockBlob.SnapshotQualifiedUri.ToString());
db.Save();
}
Or should be a better approach to use a try catch block?
try
{
using (Stream fileStream = file.InputStream)
{
blockBlob.UploadFromStream(fileStream);
}
}
catch(Exception)
{
//do something
}
Urls.Add(blockBlob.SnapshotQualifiedUri.ToString());
db.Save();
Please explain in your answer the differences between each approach, personally I think that a try catch should be a better approach but I want to confirm in here :)

Normally incases like this, I go a combination of the two and create a method that handles the upload and returns true or false depending on whether the upload was successful, or an exception occurred.
The try catch allows for any potential exceptions to handled appropriately, and the flag becomes simply an indicator to inform you whether the process succeeded or not.
For example, for your upload code, I would create an extension method like this:
public static bool TryUploadFile(this CloudBlockBlob blockBlob, File file)
try
{
using (Stream fileStream = file.InputStream)
{
blockBlob.UploadFromStream(fileStream);
}
return true;
}
catch(Exception)
{
//do some logging or other error handling
}
return false;
}
And then call the method like so:
bool succeeded = blockBlob.TryUploadFile(file);
if (succeeded)
{
Urls.Add(blockBlob.SnapshotQualifiedUri.ToString());
db.Save();
}

Generally the decision about whether to use exceptions or a return value that indicates whether the function succeeds depends on the chances of failure of the function.
Exception handling is fairly expensive, but if it is only used in exceptional cases then this should not lead to performance problems.
The advantage of exception handling is that it makes your code look much cleaner, better to understand and easier to maintain and change.
The lack of a return value that indicated whether the action succeeded or not, usually gives an indication that it is quite exceptional that the action does not succeed. This in contrary to, for instance, opening a file, which quite often might fail and thus uses a return value to report failure.
All three functions you use, UploadFromStream, Add, and Save do not use a return value indicating success (or at least you don't think you need these return values), so it is assumed that these functions seldom fail.
In such cases I'd use the exception method. The code could would look much cleaner:
public void Upload(...)
{
try
{
using (Stream fileStream = file.InputStream)
{
blockBlob.UploadFromStream(fileStream);
}
Urls.Add(blockBlob.SnapshotQualifiedUri.ToString());
db.Save();
}
catch(Exception exc)
{
ProcessProblem(exc);
throw new MyUploadException(..., exc);
// or just throw exc
}
}
Now your code looks fairly straightforward. You don't have to remember your progress using temporary variables, and if anything goes wrong, your logging will happen. Note that this will even be the case if the exception is thrown on unexpected places, like when the Dispose at the end of your using statement goes wrong!
This function is also better maintainable. If you add an extra function where it is also fairly exceptional that it fails, just add it, and your catch block will handle the problems.
So the basic rule: if failure is exceptional, use exceptions. Otherwise use return values.

How to catch InvalidOperationException thrown by Deserialize method

I use following code to read data from XML
var temp = default(T);
var serializer = new XmlSerializer(typeof(T));
try
{
TextReader textReader = new StreamReader(fileName);
temp = (T)serializer.Deserialize(textReader);
}
catch (InvalidOperationException ioe)
{
throw;
}
I know that rethorow it is redundant part, but I wanted to throw it in controled way. I want to use this place to show the user that some XML file has been corupted (ie tag was not closed). Everything works fine until I don't leave the class and I want to catch this exception from the class which request this data. It seems that the exception is missinig and bypassed somehow, and application jump into diffrent method suddenly. Why I cannot catch this exception? I even create my own exception, but the result was the same - it seems that it just not leave original class and cause some application jump.

xml deserialization exceptions work just like any other exceptions - there are no surprises (other than it is even more important than usual to check the .InnerExceptions (recursively), because all the interesting information is nested a few exceptions down).
Is this perhaps simply that you are catching the wrong kind of exception? For example, there is no guarantee it is an InvalidOperationException. As long as the calling method has a try with a catch(Exception ex), it should catch any exception that happens during deserialization.

I found the reason. Method which throw that exception was called by static class constructor. And it was why exception wasn't thrown up. Static constructors are called on the begining and they just don't throw exceptions (do they?). I changed original code by extracting method from xonstructor and by calling it manualy - now I can catch exception in above layer.

you can use XSD to validate that, there is the only way dynamic that i know to make this kind of validation, this Link could help

IOException vs checking File.Exists?

(I've searched similar threads and couldn't find anything that addressed this particular issue, though there were several similar such as here and here.)
I'm evaluating performance of our app and I'm noticing that we're getting some IOExceptions "Cannot locate resource". I'm not sure exactly how many times it's happening (largely depends on how user uses the app), but it's at least a dozen or so.
I'm assuming that exceptions in general are performance expensive as are File I/O calls like File.Exists(). I know that it's always good practice to check if a file exists before you try and load it. My question is, how much performance gain would I see if I check if this particular file existed? (Again, ignore the "you should do this anyway", I'm just trying to get an understanding of performance).
Option 1:
try
{
return (ResourceDictionary) Application.LoadComponent(uri);
}
catch (Exception)
{
//If it's not there, don't do anything
}
This doesn't make an extra IO call, but sometimes throws and exception which is swallowed.
Option 2:
if(File.Exists(uri))
{
return (ResourceDictionary) Application.LoadComponent(uri);
}

In general, if the file should exist (ie: it's part of your application's deployment), then I'd use the exception checking, and nothing else. This is because, in this case, the exception is truly an exceptional and unexpected circumstance.
If the file is something that is input by the user, checking for existence becomes potentialy meaningful. However, this still doesn't eliminate the need for exception handling, as the file could be deleted between the time you check and the time you open/use it. As such, you'd still need the exception handling - in which case you may want to still just use your first option code, but make sure the exception handling is clean enough to always provide a behavior, even if the file doesn't exist.

I can't see there being a big performance difference between your two options. Most of the work is locating and reading the file so in both cases you have to do that. What might be useful is caching the result if you don't expect the user add/remove this file while the application is running. So you might do something like
private static Dictionary<Uri, ResourceDictionary> _uriToResources =
new Dictionary<Uri, ResourceDictionary>();
public static ResourceDictionary GetResourceDictionary(Uri uri)
{
ResourceDictionary resources;
if (_uriToResources.TryGetValue(uri, out resources))
{
return resources;
}
try
{
resources = (ResourceDictionary)Application.LoadComponent(uri);
}
catch
{
// could prompt/alert the user here.
resources = null; // or an appropriate default.
}
_uriToResources[uri] = resources;
return resources;
}
This would prevent you from repetitively trying to load a resource that does not exist. Here I return a null object but it may be better to use some default as a fallback.

File.Exists does internally throw exceptions as well. So the performance will be very similar.
Here is the code from File.cs which contains the helper method which File.Exists calls.
[SecurityCritical]
private static bool InternalExistsHelper(string path, bool checkHost)
{
try
{
if (path == null || path.Length == 0)
return false;
path = Path.GetFullPathInternal(path);
if (path.Length > 0 && Path.IsDirectorySeparator(path[path.Length - 1]))
return false;
FileIOPermission.QuickDemand(FileIOPermissionAccess.Read, path, false, false);
return File.InternalExists(path);
}
catch (ArgumentException ex)
{
}
catch (NotSupportedException ex)
{
}
catch (SecurityException ex)
{
}
catch (IOException ex)
{
}
catch (UnauthorizedAccessException ex)
{
}
return false;
}

c# exception handling, practical example. How would you do it?

I'm trying to get better at handling exceptions but I feel like my code gets very ugly, unreadable and cluttered when I try my best to catch them. I would love to see how other people approach this by giving a practical example and compare solutions.
My example method downloads data from an URL and tries to serialize it into a given type, then return an instance populated with the data.
First, without any exception-handling at all:
private static T LoadAndSerialize<T>(string url)
{
var uri = new Uri(url);
var request = WebRequest.Create(uri);
var response = request.GetResponse();
var stream = response.GetResponseStream();
var result = Activator.CreateInstance<T>();
var serializer = new DataContractJsonSerializer(result.GetType());
return (T)serializer.ReadObject(stream);
}
I feel like the method is fairly readable like this. I know there are a few unnecessary steps in the method (like WebRequest.Create() can take a string, and I could chain methods without giving them variables) there but I will leave it like this to better compare against the version with exception-handling.
This is an first attempt to handle everything that could go wrong:
private static T LoadAndSerialize<T>(string url)
{
Uri uri;
WebRequest request;
WebResponse response;
Stream stream;
T instance;
DataContractJsonSerializer serializer;
try
{
uri = new Uri(url);
}
catch (Exception e)
{
throw new Exception("LoadAndSerialize : Parameter 'url' is malformed or missing.", e);
}
try
{
request = WebRequest.Create(uri);
}
catch (Exception e)
{
throw new Exception("LoadAndSerialize : Unable to create WebRequest.", e);
}
try
{
response = request.GetResponse();
}
catch (Exception e)
{
throw new Exception(string.Format("LoadAndSerialize : Error while getting response from host '{0}'.", uri.Host), e);
}
if (response == null) throw new Exception(string.Format("LoadAndSerialize : No response from host '{0}'.", uri.Host));
try
{
stream = response.GetResponseStream();
}
catch (Exception e)
{
throw new Exception("LoadAndSerialize : Unable to get stream from response.", e);
}
if (stream == null) throw new Exception("LoadAndSerialize : Unable to get a stream from response.");
try
{
instance = Activator.CreateInstance<T>();
}
catch (Exception e)
{
throw new Exception(string.Format("LoadAndSerialize : Unable to create and instance of '{0}' (no parameterless constructor?).", typeof(T).Name), e);
}
try
{
serializer = new DataContractJsonSerializer(instance.GetType());
}
catch (Exception e)
{
throw new Exception(string.Format("LoadAndSerialize : Unable to create serializer for '{0}' (databinding issues?).", typeof(T).Name), e);
}
try
{
instance = (T)serializer.ReadObject(stream);
}
catch (Exception e)
{
throw new Exception(string.Format("LoadAndSerialize : Unable to serialize stream into '{0}'.", typeof(T).Name), e);
}
return instance;
}
The problem here is that while everything that could possibly go wrong will be caught and given a somewhat meaningful exception, it is a clutter-fest of significant proportions.
So, what if I chain the catching instead. My next attempt is this:
private static T LoadAndSerialize<T>(string url)
{
try
{
var uri = new Uri(url);
var request = WebRequest.Create(uri);
var response = request.GetResponse();
var stream = response.GetResponseStream();
var serializer = new DataContractJsonSerializer(typeof(T));
return (T)serializer.ReadObject(stream);
}
catch (ArgumentNullException e)
{
throw new Exception("LoadAndSerialize : Parameter 'url' cannot be null.", e);
}
catch (UriFormatException e)
{
throw new Exception("LoadAndSerialize : Parameter 'url' is malformed.", e);
}
catch (NotSupportedException e)
{
throw new Exception("LoadAndSerialize : Unable to create WebRequest or get response stream, operation not supported.", e);
}
catch (System.Security.SecurityException e)
{
throw new Exception("LoadAndSerialize : Unable to create WebRequest, operation was prohibited.", e);
}
catch (NotImplementedException e)
{
throw new Exception("LoadAndSerialize : Unable to get response from WebRequest, method not implemented?!.", e);
}
catch(NullReferenceException e)
{
throw new Exception("LoadAndSerialize : Response or stream was empty.", e);
}
}
While it certainly is easier on the eyes, I am leaning heavily the intellisense here to provide all exceptions that can possibly be thrown from a method or class. I don't feel confident that this documentation is 100% accurate, and would be even more skeptical if some of the methods came from an assembly outside the .net framework. As an example the DataContractJsonSerializer show no exceptions on the intellisense. Does this mean the constructor will never fail? Can I be sure?
Other issues with this is that some of the methods throw the same exception, which makes the error harder to describe (this or this or this went wrong) and so is less useful to the user / debugger.
A third option would be to ignore all exceptions apart from the ones that would allow me to take an action like retrying the connection. If the url is null then the url is null, the only benefit from catching that is a little bit more verbose error message.
I would love to see your thoughts and/or implementations!

Rule one of exception handling - do not catch exceptions you don't know how to handle.
Catching exceptions just in order to provide nice error messages is questionable. The exception type and message already contain enough information for a developer - the messages you have provided do not add any value.
the DataContractJsonSerializer show no exceptions on the intellisense. Does this mean the constructor will never fail? Can I be sure?
No, you can't be sure. C# and .NET in general are not like Java where you have to declare what exceptions may be thrown.
A third option would be to ignore all exceptions apart from the ones that would allow me to take an action like retrying the connection.
That indeed is the best option.
You can also add a general exception handler at the top of the application that will capture all unhandled exceptions and log them.

First, read my article on exception handling:
http://ericlippert.com/2008/09/10/vexing-exceptions/
My advice is: you must handle the "vexing exceptions" and "exogenous exceptions" that can be thrown by your code. Vexing exceptions are "non exceptional" exceptions and so you have to handle them. Exogenous exceptions can happen due to considerations beyond your control, and so you have to handle them.
You must not handle the fatal and boneheaded exceptions. The boneheaded exceptions you don't need to handle because you are never going to do anything that causes them to be thrown. If they are thrown then you have a bug and the solution is fix the bug. Don't handle the exception; that's hiding the bug. And you can't meaningfully handle fatal exceptions because they're fatal. The process is about to go down. You might consider logging the fatal exception, but keep in mind that the logging subsystem might be the thing that triggered the fatal exception in the first place.
In short: handle only those exceptions that can possibly happen that you know how to handle. If you don't know how to handle it, leave it to your caller; the caller might know better than you do.
In your particular case: don't handle any exceptions in this method. Let the caller deal with the exceptions. If the caller passes you an url that cannot be resolved, crash them. If the bad url is a bug then the caller has a bug to fix and you are doing them a favour by bringing it to their attention. If the bad url is not a bug -- say, because the user's internet connection is messed up -- then the caller needs to find out why the fetch failed by interrogating the real exception. The caller might know how to recover, so help them.

First of all, you should, for all practical purposes, never throw type Exception. Always throw something more specific. Even ApplicationException would be better, marginally. Secondly, use separate catch statements for different operations when, and only when, the caller will have reason to care which operation failed. If an InvalidOperationException that occurs at one point in your program will imply something different about the state of your object than one which occurs at some other time, and if your caller is going to care about the distinction, then you should wrap the first part of your program in a 'try/catch' block which will wrap the InvalidOperationException in some other (possibly custom) exception class.
The notion of "only catch exceptions you know how to handle" is nice in theory, but unfortunately most exception types are so vague about the state of underlying objects that it's almost impossible to know whether one can "handle" an exception or not. For example, one might have a TryLoadDocument routine which must internally use methods that might throw exceptions if parts of the document cannot be loaded. In 99% of cases where such an exception occurs, the proper way to "handle" such an exception will be to simply abandon the partially-loaded document and return without exposing it to the caller. Unfortunately, it's very difficult to identify the 1% of cases where that is insufficient. You should endeavor to throw different exceptions in the cases where your routine has failed without doing anything, versus those where it may have had other unpredictable side-effects; unfortunately, you'll probably be stuck guessing at the interpretation of most exceptions from routines you call.

Exception e.message should have more than enough error message data for you to debug it properly. When I do exception handling I generally just logfile it with some short information about where it happened, and the actual exception.
I wouldn't split it like that, that just makes a mess. Exceptions are mostly for YOU. Ideally if your user is causing exceptions you would have caught them earlier.
I wouldn't recommend throwing different named exceptions unless they're not really exceptions (for example sometimes in certain API calls the response becomes null. I'd usually check for that and throw a helpful exception for me).

Look at Unity Interception. Within that framework, you can use something called an ICallHandler, which allows you to intercept calls and do whatever you need/want to do with the intercepted call.
For example:
public IMethodReturn Invoke(IMethodInvocation input,
GetNextHandlerDelegate getNext)
{
var methodReturn = getNext().Invoke(input, getNext);
if (methodReturn.Exception != null)
{
// exception was encountered...
var interceptedException = methodReturn.Exception
// ... do whatever you need to do, for instance:
if (interceptedException is ArgumentNullException)
{
// ... and so on...
}
}
}
There are other interception frameworks, of course.

Consider splitting the method into smaller ones so error handling can be done for related errors.
You have multiple semi-unrelated things happening in the same method, as result error handling have to be more or less per line of code.
I.e. for your case you can split method into: CreateRequest (handle invalid arguments errors here), GetResponse (handle network errors), ParseRespone (handle content errors).

I do not agree with #oded when he says:
"Rule one of exception handling - do not catch exceptions you don't know how to handle."
It may be OK for academic purposes, but in real life your customers do not want non informative errors popping up on their faces.
I think you can and should catch exceptions and them generate some informative exception to the user. When an nice error, well informative, is shown to the user it can have more information about what he/she should do to solve the problem.
Also, catching all exception can be useful when you decide to log errors or, even better, send them to you automatically.
All my projects have a Error class and I always catch every exception using it. Even though i dont do much on this class, it is there and it can be used to a lot of things.