@gvergnaud What's your opinion about this feature? We need a way to catch both compile-time and runtime errors. Currently exhaustive and otherwise provide just one of the errors (compile-time and runtime, respectively)

I'm still considering it, but I'm not sure what's the best option in terms of API complexity / typesafety yet. In the meantime, this work around doesn't seem too bad:

try {
  return match(...).with(...).exhaustive()
} catch (e) {
  return defaultValue
}

@gvergnaud it looks great imo. Are you ok with the breaking changes? Don't you prefer a backward-compatible change?

EDIT: I wasn't aware that .exhaustive() throws an error currently. I thought you suggested it as a PR. I dived into the code and found it.
Maybe the solution is to mention it in the docs because I think all related issues aren't aware of that. At least I wasn't aware.
And a suggestion, maybe it should throw a custom error, instead of a generic Error, so it will be easy to catch. (for example error instanceof PatternMatchingError instead of error.message.includes('Pattern matching error')

#253 was merged, adding an optional fallback function to .exhaustive which covers the same use case as .safeExhaustive proposed here. Closing