suggestion: don't use std/assert in implementation code #4865
Closed
Description
Using assertions from std/assert within implementation code in the codebase has a few drawbacks:
- In cases where the user needs to error handle an API that uses assertions from
std/assert, they need to import and useAssertionError. - While error messages provide the majority of the context behind an error, the constructor name does, too. I.e.
RangeError.AssertionErroris generic and doesn't add any context to the error. - It introduces an added dependency. In most cases, this doesn't matter. But for some, it does.
For these reasons, I suggest that we remove the use of assertions from std/assert within the implementation code in the Standard Library and instead use native error classes where possible. In cases where these native error classes do not fit, we can create and export custom error classes that extend Error. Doing so requires minimal code changes and can be more explicit than calling a generic assertion.
- refactor(async): cleanup use of
@std/assert#4950 - refactor(fs): cleanup use of
@std/assert#4948 - refactor(cli): cleanup use of
@std/assert#4966 - refactor(jsonc): cleanup use of
@std/assert#4968 - refactor(log): cleanup use of
@std/assert#4973 - refactor(http): cleanup use of
@std/assert#4974 - refactor(archive): cleanup use of
@std/assert#4975 - refactor(csv): cleanup use of
@std/assert#4976 - refactor(text): cleanup use of
@std/assert#4977 - refactor(webgpu): cleanup use of
@std/assert#4978 - refactor(io): cleanup use of
@std/assert#4979 - refactor(streams): cleanup use of
@std/assert#4980 - chore: document design decision to only use
@std/assertwithin testing code #5516