Nim: parseutils.parseInt shouldn't use an exception that inherits from system.Defect

[GULPF]

Exceptions that inherit from system.Defect are only supposed to be raised as a result of programmer mistakes. However, parseutils.parseInt raises OverflowError when parsing fails, which is clearly not a programmer mistake. It should raise a ValueError or similar instead.

Note that strutils.parseInt claims it raises a ValueError when parsing fails, but since it uses parseutils.parseInt internally it will raise _either_ a ValueError or a OverflowError.

Fixing this would be a breaking change.

[Araq]

Ok, but we should do it.

[GULPF]

An alternative way to fix this that I think is preferable is to stop raising exceptions in the parseutils.parseX procs and return 0 instead. They don't raise exceptions for invalid data like "abc", so it would be more consistent. It less of a breaking change as well, since existing code that uses parseutils already need to handle the case where nothing was parsed.

I'll start on a PR if this solution sounds good.

[Araq]

I don't think your proposed solution is wise. Parsing a number that happens to overflow is really different from not parsing a number at all. It should produce different error messages when exposed to a human being, for example.

[GULPF]

While revisiting this, I now realized that ValueError also inherits from Defect. Is that intentional? Most of the stdlib uses ValueError for parse errors, which are not defects. The (still open) exception rework issue even lists ValueError as a non-fatal error: #8363.

[Araq]

Seems to be an oversight indeed.