1

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?

  • 1
    What do the users of the appllication expect to happen when the date column contains something that is not a valid date? – Stop harming Monica Jan 16 '19 at 15:21
  • The purpose of an exception is to signal to other program logic that something non-standard has happened and so further processing must be modified somehow. End users seeing an exception should be, er, the exception. So the question is: Can your program do something useful about the situation (then use exception and handle it) or not (then use messages to the end user). One common way of handling an exception is producing messages. – Lutz Prechelt Jan 16 '19 at 17:22
10

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!

  • If it is being generated by a machine, there seriously should be no errors. Thanks, that was the most important part for me because probably (I'm not sure yet) this data comes from a machine / script – Joelty Jan 16 '19 at 15:24
  • 1
    @Joelty just remember that someone wrote software for that machine, and he/she is also just a human. I cannot share the sentiment that just because something is generated by machine, it will not have errors. – Atizs Jan 16 '19 at 15:25
  • @user43648 Yea, I didn't mean no validating at all – Joelty Jan 16 '19 at 15:26
  • 1
    If you are in an interactive session, by all means accept the valid part and prompt for the rest. But for the sake of all that is holy, don't guess! That way lies madness. – Deduplicator Jan 16 '19 at 15:37
  • @Atizs Oh I never said I thought generated input cannot have errors. :) I merely said that they shouldn't have errors. In case of errors, it is almost certainly something to fix in the program generating the input to your program (or tolerated if it isn't considered a problem). – Neil Jan 17 '19 at 8:49
0

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?

  • Why does this spreadsheet contain incorrect data? Spreadsheet comes from 3rd party – Joelty Jan 16 '19 at 15:20
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.