Don't want to throw an exception, should I return a custom class that holds a bool and string array?

There are certain areas in your code that you don't want the program execution to stop, like say during a checkout at a ecomm store.

I was thinking of creating a special 'return' type that looks like:

public bool SpecialReturn
{
    pu开发者_运维知识库blic bool IsSucess {get;set;}
    public List Messages {get;set;}
}

I could put an enum there to return a ReturnType etc. if I wanted.

Point being, I would then, call my CheckOut process method and return this, so I could then handle the error more gracefully.

is this a good practice?

Program execution doesn't have to stop when you hit an exception.

In general I would recommend throwing an exception when things go wrong. If you don't want that exception to bring down the program then catch it and handle it gracefully.

Of course, there are always situations where returning some sort of status object might be a better idea than throwing/catching exceptions, and your situation might be one of those, but without more information it's difficult to say.

you come from the wonderful world of C don't you?

yes, you can do that. but it wouldn't be useful... your code can still throw from the ClassLibrery and handling error codes, well sucks...

throwing exceptions don't stop the program, they just inform the upper level of an unexpected error... try...catch...

you should use exceptions, but well only in exceptional circumstances...

is this a good practice?

I'd say NOT.

Create your own subclass of Exception, add your custom properties as required (to report context info relevant to your needs) and throw.

If you use Visual Studio, there is a good code snippet for that, called Exception.

[Serializable]
public class MyCustomException : Exception
{
    public MyCustomException(string myMessage)
    {
        MyMessage = myMessage;
    }

    protected MyCustomException(SerializationInfo info, StreamingContext context)
        : base(info, context)
    {
    }

    public string MyMessage { get; private set; }
}

//...

throw new MyCustomException("Hello, world!");

If a function can succeed and return a result, or fail and not return a result you could use the same pattern that Microsoft does in a number of places. TryParse being a perfect example.

int result;
if ( Int32.TryParse("MyStringMayFail", out result) )
{
 // Succeeded result is usable
}
else
{
 // failed result is undefined and should not be trusted.
}

The actual return type of the method indicates success or failure, a parametrised out variable holds the 'result' of any operation the function may be performing. This style of coding enables the end user of the function to code directly on the success or failure of the function.

It is dead easy to create your own implementation of the TryParse methods, they are usually coupled with Parse methods which throw exceptions if something fails during processing.

If it is in fact an 'exceptional' case, and not just a valid failure, it is perfectly reasonable to throw an exception. In your case, you can handle the exception, and continue execution as best you can.

In the end what you are proposing is just recreating what exception handling already accomplishes for you.

Now if the failure is due to a credit card authorization failure (meaning invalid card number, connection failure would require an exception) or something like that. I would use failure codes, and error messages instead of exceptions.