Is throwing non-error values a mere misunderstading or a deliberate decision to ignore the basic best practices of the language?

[GabenGar]

At first I assumed it was a misunderstanding when reading the tutorial, but then the error boundary example throws like this too, complete with arbitrary payloads, in a typescript file, with no signature declarations.

Error handling is all over the place too, at one part it boldly assumes the return of useRouteError() is of type Error with no validation whatsoever. But in another it does go through the process of validating it with library-specific logic.

Take note the MDN article specifically states that the thrown object should be Errors or subclasses of it:

In practice, the exception you throw should always be an Error object or an instance of an Error subclass, such as RangeError. This is because code that catches the error may expect certain properties, such as message, to be present on the caught value.

All these questions popped up because I wanted to create a form which shows errors right inside it on submit if it fails for whatever reason. I assumed with all the under the hood magic react router would have this ability out of the box and I could adapt this monstrosity with no problems, but it doesn't look to be the case judging by documentation.

[sergiodxa]

Remix supports throwing anything because at the end in JS you can throw anything, Remix also supports throwing responses, if you throw a redirect from a loader or action the redirect will be followed, if you throw a json response that data will be returned from useRouteError and the response headers and status will be used in the actual response the browser receives.

If you throw anything else Remix will give you that from useRouteError. Then in your component you can do what you want to ensure the value is what you expect, maybe cast the type to be Error or validate it.

let routeError = useRouteError()
if (routeError instanceof Error) {
  // use routeError.message here
}
if (typeof routeError === "string") {
  // use just routeError here
}
// more cases

[GabenGar]

So I have to write a handler for every single primitive and non-primitive javascript type in every single place I have to deal with errors coming from react router (which is pretty much everywhere in the client code) just because react router doesn't know what type of errors it throws? This doesn't simplify anything at all, especially with the amount of indirection it employs.

[sergiodxa]

You should anyway, TS has no way to type thrown errors so even if you only throw instances of Error or subclases you would have to do error instanceof Error or error instanceof SubClassError like ZodError, TypeError, etc.

If you don't want to deal with this avoid throwing errors, instead return typed data you can use with useLoaderData to branch your UI and use ErrorBoundary only for unknown errors

[cmawhorter]

Remix supports throwing anything because at the end in JS you can throw anything, Remix also supports throwing responses [...]

I might've missed something changing, but you can throw anything in JS purely for backwards compat. 'something'.strike() exists too but it doesn't mean you should use it.

IMO, throwing a non-error is some serious stank. Why not just encapsulate the redirect behavior into a HaltAndRedirectError extends Error or whatever, and make things explicit? That'd also have the added benefit of being able to catch that and not redirect (or redirect differently) in certain situations. (Edit: Also stack traces)

I landed here today while playing around with remix and noticing the throw redirect(...) in one of the templates. I can control my code but if throw redirect is recommended, I'd imagine that has leaked into the ecosystem. Now I'm wondering what other gotchas not listed here I should be aware of?