using ref to view error

I working now on firm that using ref in every function.

The reason, is to catch errors.

There example :

//return开发者_C百科 true if the read is success
//otherwise writing to the error ,the problem 
bool ReadFile(ref string error)

Question:

How do you catching errors?

Using ref,exceptions or other way?

There are numerous alternatives to using ref string sError on every function as an input but still being able to check for errors using a boolean comparison.

Here's one pattern I've used in the past: create an OperationError object that you return from method that can report error information. Better yet, make it implicitly convertible to bool to make it easier to test when you don't care about the message.

Here's an example:

public sealed class OperationError
{
    public bool IsError { get; private set; }
    public string ErrorMessage { get; private set; }

    public static implicit operator bool( OperationError err )
    { 
        return IsError;
    }

    // returned to indicate success
    public static readonly OperationError Success = 
         new OperationError();

    private OperationError() {}

    public OperationError( string errorMessage )
    {
        ErrorMessage = errorMessage ?? "Unknown error";           
    }
}

// here's a case that demonstrates the usage:
public OperationError SomeMethod()
{
    if( someError() )
       return new OperationError( "someError failed, oops!" );

    return OperationError.Success; // all is well...
}


// somewhere else in your code...
var result = SomeMethod();
if( result.IsError )
    Console.WriteLine( result.ErrorMessage );

// alternatively...use the implicit bool conversion...
if( !SomeMethod() )
    throw new ApplicationException( "Oh no!" );

I think that exceptions are the most convenient, robust and natural way to provide an error handling mechanism. They are just so feature-rich comparing to error codes and other things. The main problem is to actually classify an abnormal situation like 'exceptional'. If the situation is not 'exceptional', than the above tactics is just fine.

This is an accepted pattern, in some cases. You can see it in methods like int.TryParse(...) and all the other Try... methods in the framework (although they implement it better IMO). But it shouldn't be used exclusively and instead of exceptions. Exceptions aren't perfect, but they offer much more flexibility and control than this. This is basically returning to the world of HRESULTs and ints to indicate error/success, and we got away from that style with good reason.

Use exceptions for exceptional circumstances (i.e. things that should never happen or that are outside your control).

You can use a return type (you are using a bool) to indicate whether an operation was successful or not.

Personally, I don't like ref parameters as they have very specific type constraints (i.e. not polymorphic - you have to use the type passed in) and assume side affects by the function they get passed in to.

I would put the

bool ReadFile(ref string error)

in a try catch block and not use a ref string. Try catch is the generally accepted way of catching and handling errors.

If you are using .net 4.0 and you are really against throwing exceptions you can use a Tuple too:

Tuple<bool, string>

so:

private Tuple<bool, string> ReadFile()
{
...
}