Saving type of repeated exception

Question

I am writing a class that performs operations on multiple threads. Here is an example of what I'm doing now

Dictionary<int, int> dict = new Dictionary<int, int>(_Streams.Count); for (int i = 0; i < _Streams.Count; i++) { try { dict.Add(i, _Streams[i].Read(buffer, offset, count)); } catch (System.IO.IOException e) { throw new System.IO.IOException(String.Format("I/O exception occurred in stream {0}", i), e); } catch (System.NotSupportedException e) { throw new System.NotSupportedException(String.Format("The reading of the stream {0} is not supported", i), e); } catch (System.ObjectDisposedException e) { throw new System.ObjectDisposedException(String.Format("Stream {0} is Disposed", i), e); } } int? last = null; foreach (var i in dict) { if (last == null) last = i.Value; if (last != i.Value) throw new ReadStreamsDiffrentExecption(dict); last = i.Value; } return (int)last; 

I would like to simplify my code to

 Dictionary<int, int> dict = new Dictionary<int, int>(_Streams.Count); for (int i = 0; i < _Streams.Count; i++) { try { dict.Add(i, _Streams[i].Read(buffer, offset, count)); } catch (Exception e) { throw new Exception(String.Format("Exception occurred in stream {0}", i), e); } } int? last = null; foreach (var i in dict) { if (last == null) last = i.Value; if (last != i.Value) throw new ReadStreamsDiffrentExecption(dict); last = i.Value; } return (int)last; 

However, if someone tries to catch certain exceptions, my shell will hide the exception that Read will read. How to save the type of exception, add additional information, but you do not need to write a handler for every possible unexpectedness in the try block.

Answer 1

I would suggest not catching these exceptions at all ...

The information you added (mainly) can be gleaned from stackdump.

You can use catch-and-wrap to translate to a library specific exception:

  catch (Exception e) { throw new ReadStreamsErrorExecption( String.Format("Exception occurred in stream {0}", i), e); } 

Answer 2

I think you have a little problem here when you work with your exception.

• You should not throw an Exception base class, but something more specific so that they can handle it.
• Is the id value something really “valuable” from the diagnostic function?

I would consider what you are doing and see if you really need to throw an exception.

Answer 3

I believe the first version is better for readability and more expressive to my eye. This is how exception handling should be handled.

Answer 4

Typically, the rule that I have chosen from Eric Lipperts blogs is that you only need to catch an exception if you are going to do something.

Here you simply throw the exception with a new message. Just let the client handle the exceptions yourself if you don't try to fix the errors. In this case, add

 throw; 

If you need to back up the exception because you cannot handle it.

Answer 5

One little known .NET trick is that you can add information to Exception without wrapping it. Each exception contains a .Data dictionary, which may contain additional information, such as

 try { ... } catch (FileNotFoundException ex) { ex.Data.Add("filename", filename); throw; } 

Now in your top-level exception handling code, you can drop the exception and its associated dictionary into the log file or in your Exclusions database and thus get much more information than before.

In an ASP.NET application, you can add the URL, username, referrer, cookie contents, ... to the .Data dictionary before allowing your application's error handler to accept it.