I have a data access class that uses structured error handling. If a data access operation fails, the exception is analyzed and any error information is stored to an ErrorInfo property of the data access object.

The data access object is at the end of a chain of objects beginning with the UI, extending through application-specific and base business objects to the data access object. In the case of data retrieval operations, the data access object's methods are designed to return a DataSet, and at any point my code is checking for the existence of at least one DataTable in the DataSet, under the assumption that if there is no DataTable, an error occurred. Each class then retrieves the error information from the object that returned the DataSet, and stores this to a public property thus exposing the error information to the next object in the chain. What I have is a chain-of-responsibility design pattern, with the UI eventually responsible for informing the user that it was unable to update

My question is, is there a better way of determining if an error occurred other than checking for the absence of a DataTable? Note that even if the query returns a zero-record result set, that the DataTable is still created. Would it be better to set a separate property to flag for the existence of an error condition, or perhaps use a typed DataSet or something that would carry both the fact of, and information about the error condition from one layer to the next?

Thanks for any thoughts.