Is avoiding throwing an exceptions OK?

Question

e.g I'm parsing whole Excel file with many rows, that has an column which contains Date.

I'm not sure how to handle error-handling when it comes to parsing string to DateTime

Here's an sample code which is in C#

for (int i = 1; i < sheet.RowsCount; i++)
{
    // cells are strings
    var cells = sheet.GetRow(i).Cells;

    (...)

    if (!DateTime.TryParse(cells[1], out DateTime date))
    {
        Console.WriteLine($"Unable to parse DateTime for row {i}");
        continue; // <--- here, basically skip current on fail and go to next.
    }
}

---

for (int i = 1; i < sheet.RowsCount; i++)
{
    // cells are strings
    var cells = sheet.GetRow(i).Cells;

    (...)

    if (!DateTime.TryParse(cells[1]), out DateTime date))
    {
        throw new Exception($"Problem with parsing DateTime at {i} row"); // <--- here
    }
}

Is 1st approach ok to do that?

Isn't it something like "hidden behaviour"? It may be confusing that e.g file contains 300 rows, but my function returned only 270.

Should my program yell loudly when it fails (with an exception) or just perform its job "properly", with "silent" Console Logs?

Answer 1

This depends entirely on your specifications. Is it absolutely positively crucial that all 300 lines are processed correctly? If so, throw an exception. The job should abruptly end halting and screaming. Just be sure to indicate the offensive line so that debugging potential problems later is somewhat straightforward.

Is it okay to partially process some lines? If so, simply make it evident to anyone who needs that file that that line is not valid. Better still, write to a separate file, so the usable lines aren't jumbled with the unusable lines.

If there is no clear indication one way or the other, then the deciding factor for me would be whether that input is coming from a user or if it is generated by a machine. If it is being generated by a machine, there seriously should be no errors. If there are, something is seriously fubar here and you should throw an exception to the moon.

If the input is coming from a user, expect mistakes. Mistakes can and will happen, and your focus should be on being "nice" and not simply outright rejecting the file if something is still salvageable (assuming again, that you can do without every line being valid).

Good luck!

Answer 2

What does your application require? I'd regard a file with incorrectly formatted rows as broken. An exception isn't magic, some bit of code still has to handle the exception somewhere.

So decide what is sane for your application. Perhaps each row is independent and you're trying to process as many as possible. In which case discard improperly formatted rows. Perhaps at the end generate a report that states how many were successfully processed and how many were discarded.

Why does this spreadsheet contain incorrect data?

Answer 3

If the error can be fixed by the user, or if the possibility of errors are reasonably small, then an alert with each is good in addition to logging. If the user can't do much about it, there would be no reason to bombard her with 100 messages!. In some cases, the core component of the application need to tolerate errors and go on after logging such errors. In such cases, the core logic should not raise errors to the GUI instead, should notify the GUI, based on the set business rules. At the end of the process the GUI could then issue 1 error message to the end-user. Certain errors can't be tolerated, such as input file not found for a conversion process for example, in such a case, user should be immediately notified and may also be offered the opportunity to correct the file name or end the process.