BREAKING(csv): remove ParseError

[timreichen]

What's changed

ParseError, which is thrown in parse(), has been removed and replaced in favor of SyntaxError. The startLine, line and column properties have been removed also. Error messages have remained unchanged.

Motivation

This change was made to align parse() with other parse() functions in the Standard Library, and JSON.parse(), which throw SyntaxError, and without any special properties. This all helps with providing consistent behavior across the Standard Library.

Migration guide

To migrate, compare against SyntaxError instead of ParseError when error-handling parse() or CsvParseStream.

- import { parse, ParseError } from "@std/csv/parse";
+ import { parse } from "@std/csv/parse";

try {
  parse(`a,b,🐱"`);
} catch (error) {
- if (error instanceof ParseError) {
+ if (error instanceof SyntaxError) {
    // ...
  }
}

[codecov]

Codecov Report

Attention: Patch coverage is 93.75000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 96.34%. Comparing base (ef28e13) to head (c713119).

Files	Patch %	Lines
csv/_io.ts	89.47%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5405      +/-   ##
==========================================
- Coverage   96.35%   96.34%   -0.01%     
==========================================
  Files         458      458              
  Lines       37751    37729      -22     
  Branches     5576     5573       -3     
==========================================
- Hits        36374    36351      -23     
- Misses       1335     1336       +1     
  Partials       42       42              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iuioiua]

Just found a nit. Otherwise, LGTM! Thanks for this. @kt3k, PTAL.

[iuioiua]

Also, it does seem like some of these changes could've been done in a separate PR. Not a deal big enough to change now or block this PR, but more for future reference.

[kt3k]

These information will be unavailable. Is that fine?

WDYT? cc @iuioiua

[iuioiua]

Ah, true. We can store this data within Error.cause.

[kt3k]

We can store this data within Error.cause.

Sounds a reasonable alternative to me. That use case is recommended in the 2nd example https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause#providing_structured_data_as_the_error_cause

But I'm a bit concerned about the unavailability of the type. err.cause seems always unknown type. The user need to check type and properties of cause before accessing it. On the other hand, if it's kept ParseError, these properties can be accessed after the user checked err instanceof ParseError, which feels a bit easier and clearer to me. What do you think?

[iuioiua]

Good point. Actually, now, I'm wondering whether it's worth having those extra details at all. JSON.parse doesn't do this. E.g. JSON.parse("[1,2,3,") throws an error with .cause undefined. We might be fine without. I suggest removing these properties. If it's a sufficiently significant issue in the future, we can revisit. WDYT?

[kt3k]

Fair enough. Let's try this and see the community reactions.

[kt3k]

LGTM

[iuioiua]

LGTM once the PR description is complete with what's changed, motivations, and migration guide.