feat: `ERROR(...)` should behave the same as `new Error(...)` when not caught at compile time.

[trusktr]

throw new Error("msg") is nice, because at runtime it will output a message to the console.

ERROR("msg") is useful for compile errors.

However, sometimes changes happen to a code base, and also we want interop with TS tooling (f.e. without using throw type narrowing does not happen, so we may write throw ERROR(...) to appease both TypeScript and AS at compile time). Due to changes in the code base, what was previously a compile time error can become a runtime error.

So as a convention, I've using throw ERROR(...) alot to appease TS tooling, attempt to catch errors at compile time, but also have something that actually works at runtime in case when that happens do to code refactorings.

Currently, when an AS module reaches an ERROR("message") at runtime, no message is logged to console. The error looks identical to new Error("message"), just without the message part included.

This is a feature idea to make it so that ERROR() causes a message to be logged if reached at runtime, just the same as if we had written new Error.

[dcodeIO]

The ERROR macro is very different from throwing, in that if one of these is reachable during compilation, compilation will fail and there won't be anything at runtime to log a message. That's by design of the macro, and there is no way to mix these conceptionally I think. For instance

function foo(a: bool): void {
  if (a) ERROR("whoops");
}

is an uncompilable function, even if a is false, since the ERROR macro is reachable statically and will abort compilation. But with compilation aborted, there is nothing to be gained from logging. You may be using ERROR wrong :)

Rules of thumb:

• If you want a directly called function to never be called for some reason, use ERROR so you get a compile-time failure when it is accidentally called. This applies to very specific use cases only, say after a deprecation of a function.
• For anything else, use throw new Error.

[trusktr]

If what you said should be true 100% of the time, then I've encountered a situation (bug?) where ERROR() does not produce a compile-time error, and when code reaches that point at runtime it will abort() without the given message. Based on what you described, this should not happen, but I definitely experience that.

This made me think that it was okay to assume it would be useful for runtime or compiletime depending on the code.

[trusktr]

The reason I thought I should use throw ERROR() instead of just ERROR() (under the situation I encountered where it does pass along to runtime) is to cause TypeScript to type narrow.

[trusktr]

To be more specific, I originally had code using throw new Error(...) that was properly type narrowing in TypeScript, but then I thought, hey, maybe I can make this particular error happen at compile time to make people aware of it sooner, so I changed it to ERROR(...), then I realized this prevented TypeScript from type narrowing, so I changed it to throw ERROR(...) and that did the type-narrowing trick (and for whatever reason it was throwing at runtime, not compile time).

[dcodeIO]

and for whatever reason it was throwing at runtime, not compile time

Ah, I think see what happens there: In the absence of exception handling throw is a stub that only superficially evaluates its argument. It does not really matter what is thrown, unless it is a new Error specifically, which will be used for the abort message. Throwing anything else, including the ERROR macro, just yields an unreachable without ever attempting to compile the argument.

[trusktr]

Ooooh, I see.

Ok so the bigger question is, how do we use ERROR() while also having type narrowing (for VS Code, for example)?

[dcodeIO]

Does making ERROR return never in the definitions help perhaps, so TS can see that execution ends there?

[trusktr]

Does seem like that works: TS playground

[dcodeIO]

Interesting in making a PR? :)

[trusktr]

This looks like a good first issue! :)