Read table row with multiple options

I developing an algorithm to read a row from a table (specifically, I'm reading from an Excel file).

I have three conditions about when to terminate the Read operation:

• When an empty cell is found (recognized by an ElementNotFoundException

• When a cell with errors is found (which corresponds to a null value)

• Both the two previous conditions

This is the current algorithm:

```
public IEnumerable ReadRow(string spreadsheet, int column, int row, ReadOptions readOptions = ReadOptions.ReadUntilEmpty)
{
var values = new List();

if (readOptions.HasFlag(ReadOptions.ReadUntilEmpty) && readOptions.HasFlag(ReadOptions.ReadUntilCellError))
{
try
{
for (var currentColumn = column; ; currentColumn++)
{
var value = ReadCell(spreadsheet, currentColumn, row);

// Cell has errors, so we exit from the loop
if (value == null) break;

values.Add(value);
}
}
catch (ElementNotFoundException)
{
// The row is terminated
// so we exit the loop withouth loggin any error
}
}
else if (readOptions.HasFlag(ReadOptions.ReadUntilCellError))
{
for (var currentColumn = column; ; currentColumn++)
{
try
{
var value = ReadCell(spreadsheet, currentColumn, row);

// Cell has errors, so we exit from the loop
if (value == null) break;

values.Add(value);
}
catch (ElementNotFoundException)
{
// The ReadOptions is not setted on ReadUntilEmpty
// so we just ignore empty cells
}
}
}
else if (readOptions.HasFlag(ReadOptions.ReadUntilEmpty))
{
try
{
for (var currentColumn = column; ; currentColumn++)
{
var value = ReadCell(spreadsheet, currentColumn, ro

• You always terminate the reading of the row if the element isn't found. This means you can have just one Try-Catch block that wraps your If statement.

• Instead of checking for && in your first statement, use || (or instead of and). You don't really care if ReadUntilEmpty is set at that point; only ReadUntilCellError matters. This eliminates an entire block from the If statement.

-
You could go one step further and only check the flag just before, or with, the null value check.

public IEnumerable ReadRow(string spreadsheet, int column, int row, ReadOptions readOptions = ReadOptions.ReadUntilEmpty)
{
    var values = new List();

    try
    {
        for (var currentColumn = column; ; currentColumn++)
        {
            var value = ReadCell(spreadsheet, currentColumn, row);

            if readOptions.HasFlag(ReadOptions.ReadUntilCellError))
            {
                // Cell has errors, so we exit from the loop
                if (value == null) break;
            }

            values.Add(value);
        }
    }
    catch (ElementNotFoundException)
    {
        // The row is terminated
        // so we exit the loop withouth loggin any 
    }

    return values;
}

Ultimately I realized there's never actually a need to check the ReadUntilEmpty flag, so you could probably just drop the Enum and change ReadUntilError to a Boolean with a default value of false.

Abstracting this to work on columns instead of rows is easy. The logic doesn't change at all. You just call it with the row number passed into the column argument and the column number passed into the row argument. So, really, naming the hard part and I'm drawing a blank on any actually useful names, but for the sake of giving an example...

public IEnumerable ReadRow(string spreadsheet, int iteratorIndex, int secondaryIndex, ReadOptions readOptions = ReadOptions.ReadUntilEmpty)
{
    var values = new List();

    try
    {
        for (var index = iteratorIndex; ; index++)
        {
            var value = ReadCell(spreadsheet, index, secondaryIndex);

            if readOptions.HasFlag(ReadOptions.ReadUntilCellError))
            {
                // Cell has errors, so we exit from the loop
                if (value == null) break;
            }

            values.Add(value);
        }
    }
    catch (ElementNotFoundException)
    {
        // The row is terminated
        // so we exit the loop withouth loggin any 
    }

    return values;
}

One final note: I'm not entirely comfortable with the fact that the catch block doesn't actually contain any code. It feels a bit hacky.

StackExchange Code Review Q#57658, answer score: 5