Exception or Return Status for Component that can Process with Errors

I'm currently designing a system which handles the processing of different types of files. I have defined the following interface

public interface IFileProcessor
{
    bool ProcessFile(string fileContents)
}

with the aim of creating a number of concrete implementations to process different file types. A controller class will be responsible for:

• Watching a folder for a newly added file
• Reading the file contents
• Obtaining a collection of these IFileProcessor concrete implementations
• One by one call the ProcessFile() on each component, passing the file contents
• If a component cannot process the file it returns false, otherwise it will process the contents and return true
• If no IFileProcessor implementation can process the file it is moved by the controller to a 'UnProcessed' folder
• If a component successfully processes the file it is moved to the 'Processed' folder
• If an exception is thrown by a component it is moved to a 'Failed' folder

I am creating an implementation of IFileProcessor which will firstly check if it can process the file based on the type (i.e. csv) and will then perform some top level validation (i.e. check file headers). If any of these checks fail an exception will the thrown to the controller, as the entire file is seen as invalid.

However once the top level validation has been successful the component will process each line in the file. From this point onwards it is acceptable for an individual line to fail processing (i.e. validation), and the rest of the process to continue.

This is where the problem lies, I am wondering if its best to log that validation errors have occurred and then throw an exception at the end of th开发者_JAVA百科e process, or to change the ProcessFile() signature to return an enum (one of Processed, UnProcessed, ProcessedWithErrors)?

From what I have read it seems that exceptions are the preferred route over status codes, however in this particular circumstance where a process can continue it seems wrong to use an artificial exception at the end to state the process did not complete 100%.

I would be really interested in peoples thoughts on this.

One suggestion:

Instead of returning a bool or an enum, have it return an object which callers can inspect. Maybe call it FileProcessorResult. In the object you can store all kinds of information like overall success or failure, validation status, processing status, etc.

In cases of severe failure, I would return an exception back, so correct action could take place by the caller. You could derive an exception class so that the try catch is clean.

Example:

try
{
    FileProcessorResult fpr = ProcessFile(Contents);
    //Do something with fpr

}
catch (FileProcessorException fpe)
{
   //Something unexpected occured during file processing, handle it
}

There is probably no absolute correct answer I can give, so please take this as a suggestion.

I don't believe this to be an absolute question, as in I don't see a clear do this/do that answer...

I agree with you though, it does seem weird to throw an exception at the end of the function to signal partial processing, I would also go with the return code and throw an exception when the function failed completely (i.e. failed to read from file, etc.).

One good reason for this is that the exception might not be handled in the calling function, and you probably don't want execution to stop if the file was partially processed, right?

Whichever road you choose, you need to thoroughly document the return codes/exceptions thrown, others will thank you for it.