object design advice

[mit99mh]

I'm pretty new to OO and was wondering is it best to handle exceptions within an object and provide feedback to the user or let the exception be handled in code or throw a new exception containing a custom message:

eg In the example below I handle the exception in the object and set a bool to false and provide feedback to the user from the object if an exception occurs.

Is this an appropriate way of using exceptions or should I throw an exception from this object or not do anything and just let the object be caught in code.

Any help / advice / urls on good object design appreciated.

public class SchemaValidator
{
private string xsdSchemaFilePath;
private bool fileIsValid;
private StringBuilder failureLog;

//constructor ommitted

public void validate()
{
XmlSchemaCollection xsc = new XmlSchemaCollection();
xsc.Add( this.nameSpace, this.xsdSchemaFilePath );

try
{
//code that may produce exception
}
catch
{
this.failureLog.Append( "The XML document " );
this.failureLog.Append( this.xmlFilePath );
this.failureLog.Append( " is not well formed|" );
this.fileIsValid = false;
}
finally
{
//clean up
}
}

public bool FileIsValid
{
get
{
return this.fileIsValid;
}
}

public string FailureLog
{
get
{
return this.failureLog.ToString();
}
}
}

 

[chiph]

The rule we follow around here is that exceptions are not thrown for data problems. Use of them is reserved for truly exceptional conditions, like not being able to connect to the database, MSMQ not found, etc. This is because throwing an exception is a very expensive process (there's a lot of reflection that happens to build the stacktrace, etc) and we want to minimize the time spent on that.

Obviously, sometimes exceptions get thrown from the framework for reasons of bad data (ArgumentException, etc). We catch those at the lowest level we can, transfering them into a DataError class, which gets added to a DataErrors collection, which gets passed back up the call stack. At the layer boundary between the presentation code and the back-end code, that info gets logged, and the error(s) get translated into something more user-friendly ("Couldn't add Invoice", vs "Primary key constraint failed for t_Invoice").

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[obislavu]

public class SchemaValidator
{
    private string xsdSchemaFilePath;
    private bool fileIsValid;   
    private string sErr;
   //constructor ommitted
    
    public void validate()
    {
        XmlSchemaCollection xsc = new XmlSchemaCollection(); 
        xsc.Add( this.nameSpace, this.xsdSchemaFilePath  ); 
          
        try 
        { 
                 //code that may produce exception
        } 
        catch (Exception ex)
        { 
            sErr=ex.GetType() + ex.Message + " The XML document " + this.xmlFilePath + "is not well formed|";
            this.fileIsValid = false;
                      
        } 
        finally
        {
            //clean up
        }        
    }
        
    public bool FileIsValid
    {
        get
        {
            return this.fileIsValid;
        }
    }
    public string FailureLog
        {
            get
            {
            return sErr; 
            }
        }


   
}

In the above example the client of this class should know that when calling validate on SchemaValidator object there is a bool member and a string member to get info about the result of about the state of this object.

public class SchemaValidator
{
    private string xsdSchemaFilePath;
    private bool fileIsValid;   
    //constructor ommitted
    
    public void validate()
    {
        XmlSchemaCollection xsc = new XmlSchemaCollection(); 
        xsc.Add( this.nameSpace, this.xsdSchemaFilePath  ); 
          
        try 
        { 
                 //code that may produce exception
        } 
        catch (Exception ex)
        { 
            sErr=" SchemaValidator:validate():The XML document " + this.xmlFilePath + "is not well formed|" + ex.GetType() + ex.Message ;
            this.fileIsValid = false;
            throw new Exception (sErr);
            
        } 
        finally
        {
            //clean up
        }        
    }
        
    public bool FileIsValid
    {
        get
        {
            return this.fileIsValid;
        }
    }

   
}

In the above case you forward the exception with your custom message and the client of this class will capture this message when calling validate() and an exception is caught.
For a project, you should derive a class from Exception class and put there what is nedeed for your project e.g. maybe for each object you store the state of that object, or create every time an Excepetion object and throw it , or log in the Event Viewer or a specific log file.
-obislavu-