We Keep Coding

How can I have an exception show in debugging output that doesn't cause a "catch"

This may be a basic question but I have not been able to find an answer from searching. I have code that is causing an exception to be written to the Output -> Debug window in Visual Studio. My try...catch is proceeding to the next line of code anyway. The exception is with a NuGet package.
Does this mean an exception is happening in the NuGet package and is handled by the Nuget package? How can I troubleshoot this further?
private void HandleStorageWriteAvailable(IXDocument doc)
{
using IStorage storage = doc.OpenStorage(StorageName, AccessType_e.Write);
{
Debug.WriteLine("Attempting to write to storage.");
try
{
using (Stream str = storage.TryOpenStream(EntityStreamName, true))
{
if (str is not null)
{
try
{
string test = string.Concat(Enumerable.Repeat("*", 100000));
var xmlSer = new XmlSerializer(typeof(string));
xmlSer.Serialize(str, test);
}
catch (Exception ex)
{
Debug.WriteLine("Something bad happened when trying to write to the SW file.");
Debug.WriteLine(ex);
}
}
else
{
Debug.WriteLine($"Failed to open stream {EntityStreamName} to write to.");
}
}
}
catch (Exception ex)
{
Debug.WriteLine(ex);
}
}
}
The exception happens on the line using (Stream str = storage.TryOpenStream(EntityStreamName, true)) when the exception happens the code proceeds to the next line not the catch.
Is this normal behaviour if that exception is being handled by something else? I've never seen this before.

In general, a method called TrySomething will be designed so that it won't throw an exception, but return some sort of error code instead.
Check for example the Dictionary class : it has an Add method which can throw an ArgumentException if the key already exists, and a TryAdd method which instead just returns false.
Chances are, your IStorage implementation of TryOpenStream also has an OpenStream method, and the Try version is just a try/catch wrapper which outputs the error to the Console in case of error.

How do you know it happens on that line?
However there is a setting that enables breaking handled exception in "Exception Settings" dialog (Ctrl+Alt+E). For each type of exception you can control. Here is a link that explain how it works : https://learn.microsoft.com/en-us/visualstudio/debugger/managing-exceptions-with-the-debugger?view=vs-2022

What exceptions can occur when saving an XDocument?

In my C# application I'm using the following statement:
public void Write(XDocument outputXml, string outputFilename) {
outputXml.Save(outputFilename);
}
How can I find out which exceptions the Save method might throw? Preferably right in Visual Studio 2012 or alternatively in the MSDN documentation.
XDocument.Save does not give any references. It does for other methods, e.g. File.IO.Open.

Unfortunately MSDN do not have any information about exceptions thrown by XDocument and many other types from System.Xml.Linq namespace.
But here is how saving implemented:
public void Save(string fileName, SaveOptions options)
{
XmlWriterSettings xmlWriterSettings = XNode.GetXmlWriterSettings(options);
if ((declaration != null) && !string.IsNullOrEmpty(declaration.Encoding))
{
try
{
xmlWriterSettings.Encoding =
Encoding.GetEncoding(declaration.Encoding);
}
catch (ArgumentException)
{
}
}
using (XmlWriter writer = XmlWriter.Create(fileName, xmlWriterSettings))
Save(writer);
}
If you will dig deeper, you'll see that there is large number of possible exceptions. E.g. XmlWriter.Create method can throw ArgumentNullException. Then it creates XmlWriter which involves FileStream creation. And here you can catch ArgumentException, NotSupportedException, DirectoryNotFoundException, SecurityException, PathTooLongException etc.
So, I think you should not try to catch all this stuff. Consider to wrap any exception in application specific exception, and throw it to higher levels of your application:
public void Write(XDocument outputXml, string outputFilename)
{
try
{
outputXml.Save(outputFilename);
}
catch(Exception e)
{
throw new ReportCreationException(e); // your exception type here
}
}
Calling code can catch only ReportCreationException and log it, notify user, etc.

If the MSDN doesn't state any I guess that Class won't throw any exception. Although, I don't think that this object will be responsible for writing the actual file to disk. So you might receive exceptions from other classes used by XDocument.Save();
To be on the safe side, I would trap all exceptions and try out some obvious erratic instructions, see below.
try
{
outputXml.Save("Z:\\path_that_dont_exist\\filename");
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
Here, catching Exception will catch any types of exceptions.

Catching expected exceptions

I've got code that looks like this because the only reliable way for me to check if some data is an image is to actually try and load it like an image.
static void DownloadCompleted(HttpConnection conn) {
Image img;
HtmlDocument doc;
try {
img = Image.FromStream(conn.Stream);
} catch {
try {
doc = new HtmlDocument();
doc.Load(conn.Stream);
} catch { return; }
ProcessDocument(doc);
return;
}
ProcessImage(img);
return;
}
Which looks down right terrible!
What's a nice way of handling these situations? Where you're basically forced to use an exception like an if statement?

Your logical structure is
if( /* Loading Image Fails */ )
/* Try Loading HTML */
so I would try to make the code read that way. It would probably be cleanest (though admittedly annoyingly verbose) to introduce helper methods:
bool LoadImage()
{
Image img;
try
{
img = Image.FromStream(conn.Stream);
}
catch( NotAnImageException /* or whatever it is */ )
{
return false;
}
ProcessImage(img);
return true;
}
bool LoadDocument()
{
// etc
}
So you can write
if( !LoadImage() )
LoadDocument();
or extend it to:
if( !LoadImage() && !LoadDocument() )
{
/* Complain */
}

I think empty catch blocks, the way you've coded them, are a very bad idea in general. You're swallowing an exception there. No one will ever know that something is amiss the way you've coded it.
My policy is that if I can't handle and recover from an exception, I should simply allow it to bubble up the call stack to a place where it can be handled. That might mean nothing more than logging the error, but it's better than hiding the error.
If unchecked exceptions are the rule in .NET, I'd recommend that you use just one try/catch block when you must within a single method. I agree - multiple try/catch blocks in a method is ugly and cluttering.
I'm not sure what your code is trying to do. It looks like you're using exceptions as logic: "If an exception isn't thrown, process and return an image; if an exception IS thrown, process and return an HTML document." I think this is a bad design. I'd refactor it into two methods, one each for an image and HTML, and not use exceptions instead of an "if" test.

I like the idea of Eric's example, but I find the implementation ugly: doing work in an if and having a method that does work return a boolean looks very ugly.
My choice would be a method that returns Images, and a similar method
Image LoadImage(HttpConnection conn)
{
try
{
return Image.FromStream(conn.Stream);
}
catch(NotAnImageException)
{
return null;
}
}
and do the work in the original method:
static void DownloadCompleted(HttpConnection conn)
{
Image img = LoadImage(conn);
if(img != null)
{
ProcessImage(img);
return;
}
HtmlDocument doc = LoadDocument(conn);
if(doc != null)
{
ProcessDocument(doc)
return;
}
return;
}

In conjunction to duffymo's answer, if you're dealing with
File input/output, use IOException
Network sockets, use SocketException
XML, use XmlException
That would make catching exceptions tidier as you're not allowing it to bubble up to the generic catch-all exception. It can be slow, if you use the generic catch-all exception as the stack trace will be bubbling up and eating up memory as the references to the Exception's property, InnerException gets nested as a result.
Either way, craft your code to show the exception and log it if necessary or rethrow it to be caught by the catch-all exception...never assume the code will not fail because there's plenty of memory, plenty of disk and so on as that's shooting yourself in the foot.
If you want to design your own Exception class if you are building a unique set of classes and API, inherit from the ApplicationException class.
Edit:
I understand better what the OP is doing...I suggest the following, cleaner implementation, notice how I check the stream to see if there's a HTML tag or a DOC tag as part of XHTML...
static void DownloadCompleted(HttpConnection conn) {
Image img;
HtmlDocument doc;
bool bText = false;
using (System.IO.BinaryReader br = new BinaryReader(conn.Stream)){
char[] chPeek = br.ReadChars(30);
string s = chPeek.ToString().Replace(" ", "");
if (s.IndexOf("<DOC") > 0 || s.IndexOf("<HTML") > 0){
// We have a pure Text!
bText = true;
}
}
if (bText){
doc = new HtmlDocument();
doc.Load(conn.Stream);
}else{
img = Image.FromStream(conn.Stream);
}
}
Increase the length if you so wish depending on how far into the conn.Stream indicating where the html tags are...
Hope this helps,
Best regards,
Tom.

There is no need to try to guess the content type of an HTTP download, which is why you are catching exceptions here. The HTTP protocol defines a Content-Type header field which gives you the MIME type of the downloaded content.
Also, a non-seekable stream can only be read once. To read the content of a stream multiple times, you would have to copy it to a MemoryStream and reset it before each read session with Seek(0, SeekOrigin.Begin).

Answering your exact question: you don't need a catch block at all, try/finally block will work just fine without a catch block.
try
{
int i = 0;
}
finally {}

How to check for valid xml in string input before calling .LoadXml()

I would much prefer to do this without catching an exception in LoadXml() and using this results as part of my logic. Any ideas for a solution that doesn't involve manually parsing the xml myself? I think VB has a return value of false for this function instead of throwing an XmlException. Xml input is provided from the user. Thanks much!
if (!loaded)
{
this.m_xTableStructure = new XmlDocument();
try
{
this.m_xTableStructure.LoadXml(input);
loaded = true;
}
catch
{
loaded = false;
}
}

Just catch the exception. The small overhead from catching an exception drowns compared to parsing the XML.
If you want the function (for stylistic reasons, not for performance), implement it yourself:
public class MyXmlDocument: XmlDocument
{
bool TryParseXml(string xml){
try{
ParseXml(xml);
return true;
}catch(XmlException e){
return false;
}
}

Using a XmlValidatingReader will prevent the exceptions, if you provide your own ValidationEventHandler.

I was unable to get XmlValidatingReader & ValidationEventHandler to work. The XmlException is still thrown for incorrectly formed xml. I verified this by viewing the methods with reflector.
I indeed need to validate 100s of short XHTML fragments per second.
public static bool IsValidXhtml(this string text)
{
bool errored = false;
var reader = new XmlValidatingReader(text, XmlNodeType.Element, new XmlParserContext(null, new XmlNamespaceManager(new NameTable()), null, XmlSpace.None));
reader.ValidationEventHandler += ((sender, e) => { errored = e.Severity == System.Xml.Schema.XmlSeverityType.Error; });
while (reader.Read()) { ; }
reader.Close();
return !errored;
}
XmlParserContext did not work either.
Anyone succeed with a regex?

If catching is too much for you, then you might want to validate the XML beforehand, using an XML Schema, to make sure that the XML is ok, But that will probably be worse than catching.

AS already been said, I'd rather catch the exception, but using XmlParserContext, you could try to parse "manually" and intercept any anomaly; however, unless you're parsing 100 xml fragments per second, why not catching the exception?

How to properly handle exceptions when performing file io

Often I find myself interacting with files in some way but after writing the code I'm always uncertain how robust it actually is. The problem is that I'm not entirely sure how file related operations can fail and, therefore, the best way to handle exceptions.
The simple solution would seem to be just to catch any IOExceptions thrown by the code and give the user an "Inaccessible file" error message, but is it possible to get a bit more fine-grained error messages? Is there a way to determine the difference between such errors as a file being locked by another program and the data being unreadable due to a hardware error?
Given the following C# code, how would you handle errors in a user friendly (as informative as possible) way?
public class IO
{
public List<string> ReadFile(string path)
{
FileInfo file = new FileInfo(path);
if (!file.Exists)
{
throw new FileNotFoundException();
}
StreamReader reader = file.OpenText();
List<string> text = new List<string>();
while (!reader.EndOfStream)
{
text.Add(reader.ReadLine());
}
reader.Close();
reader.Dispose();
return text;
}
public void WriteFile(List<string> text, string path)
{
FileInfo file = new FileInfo(path);
if (!file.Exists)
{
throw new FileNotFoundException();
}
StreamWriter writer = file.CreateText();
foreach(string line in text)
{
writer.WriteLine(line);
}
writer.Flush();
writer.Close();
writer.Dispose();
}
}

...but is it possible to get a bit more fine-grained error messages.
Yes. Go ahead and catch IOException, and use the Exception.ToString() method to get a relatively relevant error message to display. Note that the exceptions generated by the .NET Framework will supply these useful strings, but if you are going to throw your own exception, you must remember to plug in that string into the Exception's constructor, like:
throw new FileNotFoundException("File not found");
Also, absolutely, as per Scott Dorman, use that using statement. The thing to notice, though, is that the using statement doesn't actually catch anything, which is the way it ought to be. Your test to see if the file exists, for instance, will introduce a race condition that may be rather vexing. It doesn't really do you any good to have it in there. So, now, for the reader we have:
try {
using (StreamReader reader = file.OpenText()) {
// Your processing code here
}
} catch (IOException e) {
UI.AlertUserSomehow(e.ToString());
}
In short, for basic file operations:
1. Use using
2, Wrap the using statement or function in a try/catch that catches IOException
3. Use Exception.ToString() in your catch to get a useful error message
4. Don't try to detect exceptional file issues yourself. Let .NET do the throwing for you.

The first thing you should change are your calls to StreamWriter and StreamReader to wrap them in a using statement, like this:
using (StreamReader reader = file.OpenText())
{
List<string> text = new List<string>();
while (!reader.EndOfStream)
{
text.Add(reader.ReadLine());
}
}
This will take care of calling Close and Dispose for you and will actually wrap it in a try/finally block so the actual compiled code looks like this:
StreamReader reader = file.OpenText();
try
{
List<string> text = new List<string>();
while (!reader.EndOfStream)
{
text.Add(reader.ReadLine());
}
}
finally
{
if (reader != null)
((IDisposable)reader).Dispose();
}
The benefit here is that you ensure the stream gets closed even if an exception occurs.
As far as any more explicit exception handling, it really depends on what you want to happen. In your example you explicitly test if the file exists and throw a FileNotFoundException which may be enough for your users but it may not.

Skip the File.Exists(); either handle it elsewhere or let CreateText()/OpenText() raise it.
The end-user usually only cares if it succeeds or not. If it fails, just say so, he don't want details.
I haven't found a built-in way to get details about what and why something failed in .NET, but if you go native with CreateFile you have thousands of error-codes that can tell you what went wrong.

I don't see the point in checking for existence of a file and throwing a FileNotFoundException with no message. The framework will throw the FileNotFoundException itself, with a message.
Another problem with your example is that you should be using the try/finally pattern or the using statement to ensure your disposable classes are properly disposed even when there is an exception.
I would do this something like the following, catch any exception outside the method, and display the exception's message :
public IList<string> ReadFile(string path)
{
List<string> text = new List<string>();
using(StreamReader reader = new StreamReader(path))
{
while (!reader.EndOfStream)
{
text.Add(reader.ReadLine());
}
}
return text;
}

I would use the using statement to simplify closing the file. See MSDN the C# using statement
From MSDN:
using (TextWriter w = File.CreateText("log.txt")) {
w.WriteLine("This is line one");
w.WriteLine("This is line two");
}
using (TextReader r = File.OpenText("log.txt")) {
string s;
while ((s = r.ReadLine()) != null) {
Console.WriteLine(s);
}
}

Perhaps this is not what you are looking for, but reconsider the kind you are using exception handling. At first exception handling should not be treated to be "user-friendly", at least as long as you think of a programmer as user.
A sum-up for that may be the following article http://goit-postal.blogspot.com/2007/03/brief-introduction-to-exception.html .