It is extremely uncomfortable to catch XST-specific exceptions.

[thims]

I suggest to add a new exception class like this:

public class XstException : Exception
{
        public XstException(string message) : base(message)
        {
        }
}

And then replace all "throw new Exception(...)" and "throw new ArgumentException(...)" to "throw new XstException(...)" in all *.cs files in the project.

[Dijji]

My expectation was that exceptions will be thrown only if XstReader had some deficiency, or the file being read was corrupt. What use cases are you encountering where you need an application built on top of XstReader to capture exceptions? I’m asking because I believe that use cases should always drive design, and I don’t currently have any of my own to work off.

[thims]

or the file being read was corrupt.

This. And at the higher level you can't differentiate exceptions.

[Dijji]

Having looked at the exceptions that I throw, it would be better if I changed them to a specific exception of the sort that you suggest. I will add it to the work list.

Of course, this doesn’t guarantee that no other exceptions will ever be thrown: exceptions may be thrown by system functions that I call. The only way to guarantee isolation of all exceptions from my code is to wrap all calls into it with try/catch and throw an exception of your own.

[Dijji]

I have made the suggested changes to the source files. However, there doesn’t seem enough to justify a new release at this time, especially as the changes will only be significant to another program which embeds this one at the source level.

[Dijji]

This change was released as part of Version 1.3

Dijji