C# - Complete return from base method

Question

I have a virtual base method void Action() that is overridden in a derived class.

The first step in Action is to call base.Action(). If a situation occurs in the base method I do not want the rest of the derived method to be processed.

I want to know is there a keyword or design pattern that will allow me to exit the derived method from the base method.

Currently I am looking at changing the void to bool and using that as a flow control, but I was wondering if there are any other design patterns I might be able to use.

Caridadcarie

No it is not an error situation so exceptions won't work. – Caridadcarie

Sorry gain (deleted previous post about not needing a solution), I still need a solution, system is getting quite complex. Basically there is a credits_available variable somewhere else in the code. I would like to be able to disable all the actions in the base class if there is no credits available. I would like to be able to do this without the derived class having to duplicate the code. – Caridadcarie

Answer 1

Do not use it with void returned type, but can do, say bool

public class Base
{
    public virtual bool Action()
    {
       ..
       return boolean-value.
    }
}

public class Child : Base
{
    public override bool Action()
    {
       if(!base.Action()) 
         return false;

       ....
       return boolean-value;
    }
}

Or, if this is a exceptional situation, raise an exception, like others suggest.

Pucker

This is a bit messy as it exposes an unnecessary implementation to a consumer of the class. – Joletta

@Slugart: what implementation you're talking about? – Pucker

Sorry meant implementation detail - Action now exposes the fact that it returns bool. What does that mean to the consumer of the derived class? – Joletta

What does it mean actually, can be specified in the documentation/comments to the function. IF this is a good or bad design, depends on the concrete program architecture/design. I have no idea in what context whoud be this code used, so just offer one of possible solutions. – Pucker

If this is a good or bad design also depends on whether it respects the principles of object oriented design, one of those being encapsulation. I was just trying to point out that this design leaks an implementation detail. – Joletta

I think seems to be the simplest solution, without over-complicating the system. I will just need to document it properly. On a side note, just our of curiosity can the derived method still have the return type as void, as the returned value will never be used. – Caridadcarie

@Talib: No, the derived method can't change the return type of the method it's overriding. To be honest, if it's an implementation detail then I would try to avoid putting it in the public API. – Neurilemma

Answer 2

Is this an error "situation"? If so, just make it throw an exception, and don't catch the exception within the override.

If it's not an error situation, then using the return type does sound like a way forward, but it may not be suitable for your context - we don't really know what you're trying to achieve.

Another option is to use the template method pattern:

public abstract class FooBase
{
    public void DoSomething()
    {
        DoUnconditionalActions();
        if (someCondition)
        {
            DoConditionalAction();
        }
    }

    protected abstract void DoConditionalAction();
}

If you don't want to make the base class abstract, you could make it a protected virtual method which does nothing in the base class and is overridden in the derived class where appropriate. Note that DoSomething is not virtual here.

If none of these options sounds appropriate, you'll need to provide us more concrete information about what you're trying to achieve.

Neurilemma

Answer 3

Throw an exception in the base method. It will exit out of each method that called it, until it is caught.

Despatch

Throwing an exception in a method that is called frequently is not a very good idea. – Lawry

@Mert: it is a good idea in exceptional situation, but it's a bad idea for control flow in most cases. – Pucker

@Mert: Throwing exceptions frequently is not good, but the exception is only thrown when there is "a situation", as the OP put it. That doesn't happen every time that the method is called, as the normal flow is to run the rest of the code in the derived method. – Despatch

@Guffa: "Situation" is not an error in this case. "Currently I am looking at changing the void to bool and using that as a flow control" he is looking for a way to use that in flow control, and flow control conditions happens very frequently if not everytime. – Lawry

@Mert: That is your interpretation. Just because the OP uses the term "flow control" for handling what the code should do in different situations, doesn't mean that it can't be an error. – Despatch

@Guffa: That is my interpretation? How do you interprate "No it is not an error situation so exceptions won't work – Talib"? End of discussion. – Lawry