Unhandled Exception when encountering corrupt testArticleScraper.txt file

[Geinzit]

When testArticleScraper.txt is corrupt or manually edited to have incorrect format. The program should theoretically rerun the "Scraper" component of the program to reset the text file. But currently it leads to unhandled exception.

Hello from
__________________________________________________________________________________________
    _     _                           __             ______                     __
    /|   /                          /    )             /      /               /    )
---/-| -/-----__----------__-------/----/----__-------/------/__----__-------/---------__-
  /  | /    /___)| /| /  (_ `     /    /   /   )     /      /   ) /___)     /  --,   /   )
_/___|/____(___ _|/_|/__(__)_____(____/___/___/_____/______/___/_(___ _____(____/___(___/_

What is your name?
hmd
____________________________________________________________

Hello hmd
____________________________________________________________

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3
        at newsonthego.storage.NewsImporter.importNewsFromText(NewsImporter.java:32)
        at newsonthego.NewsOnTheGo.main(NewsOnTheGo.java:309)

[soc-se-bot]

Team's Response

Ah, I see what's happened here. You edited the scraper file, which isn't quite what we had in mind. Just a gentle reminder: the file's already set up correctly for our database, so manual adjustments aren't necessary. Running the scraper each time might slow things down a tad. Thanks for bringing it to our attention, though. Perhaps clearer documentation about not tinkering with the file would help prevent this.

Items for the Tester to Verify

:question: Issue type

Team chose [type.DocumentationBug] Originally [type.FunctionalityBug]

• [x] I disagree

Reason for disagreement: I do believe that users are unlikely to tinker the file manually. But when we are talking about corrupt files, there are situations where files become involuntarily corrupted(e.g. Hardware or storage issues, Transfer or Operating System errors etc.) So even if the documentation warned users to not tinker the file, this issue can still happen and should be prevented entirely on the software level. That's why I believe functionality bug is more appropriate.

---

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:**   Above are the definition of VeryLow Severity and Low Severity issues. I believe this issue is not cosmetic and will crash the entire program when the condition meets, despite the condition being pretty rare. So I think this issue matches the description of low severity much more than very low.

---