Richard Feldman (Oct 06 2024 at 20:52): Richard Feldman (Oct 06 2024 at 20:52):thinking about the concern raised in https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/Dealing.20with.20logic.20errors.20in.20Roc about crash being misused by library authors, I wonder if we could decrease the odds of that happening if it had a different name?
Richard Feldman (Oct 06 2024 at 20:52):for example, unrecoverable might make it more obvious when to use it
Richard Feldman (Oct 06 2024 at 20:53):or abort, although in that case it might be surprising that it doesn't always abort the process :sweat_smile:
Richard Feldman (Oct 06 2024 at 20:58):of note, one of the original reasons we decided to name it crash (as I recall) was use cases like quick scripts or coding puzzles like Advent of Code, where handling errors gracefully was just not worth the effort
Richard Feldman (Oct 06 2024 at 20:59):but now that we've figured out the basic-cli design where you can just leave errors unhandled, and the platform will report them as errors, I think we might not need that use case to be in scope anymore
Richard Feldman (Oct 06 2024 at 21:00):e.g. in the purity inference world, try will just do the same thing as crash does today (when you're using the "allow unhandled errors" style)
Richard Feldman (Oct 06 2024 at 21:02):plus try will give a helpful error message by default
Oskar Hahn (Oct 06 2024 at 21:02):You could name it "unreachable" which is the only correct situation to use it in a library. For scripts, it would be ok to "misuse" "unreachable" for a quick exit.
Richard Feldman (Oct 06 2024 at 21:02):I guess a downside of that approach is that you wouldn't get a stack trace though
Richard Feldman (Oct 06 2024 at 21:05):which for a quick script would probably be desirable
Richard Feldman (Oct 06 2024 at 21:06)::thinking: actually platforms could offer to enable stack traces in unhandled errors
Richard Feldman (Oct 06 2024 at 21:07):at least for I/O operations
Richard Feldman (Oct 06 2024 at 21:07):not for stuff like List.get
Luke Boswell (Oct 06 2024 at 21:07):I like the idea of renaming it to be clearer, maybe something even longer like crashBecauseThisIsUnreachable
Sam Mohr (Oct 06 2024 at 21:08):I think crash does a great job of mediating between "irreversibly stop doing stuff" and not explaining how in the name.
"unreachable" is a descriptor, we should probably have a verb
Sam Mohr (Oct 06 2024 at 21:08):Abort "misexplains" how it works, which is not great
Sam Mohr (Oct 06 2024 at 21:11):An obvious alternative is panic, though I understand not wanting to imply we work like Rust since there's no unwind
Brendan Hansknecht (Oct 06 2024 at 22:19):I would go with: unrecoverableCrash
Brendan Hansknecht (Oct 06 2024 at 22:20):Cause it is "unrecoverable" within Roc.
Sam Mohr (Oct 07 2024 at 00:07):It's probably okay if it's clunky
Sam Mohr (Oct 07 2024 at 00:09):I prefer something concise, but something long like that dissuades usage, which probably isn't a bad thing
Brendan Hansknecht (Oct 07 2024 at 01:52):Obviously we change the API to:
thisIsDefinitelyABugIfHit "url.to.file.bug.com" "the error message"
Jasper Woudenberg (Oct 07 2024 at 06:48):I actually kind of like Brendan's suggestion. Thinking what my ideal web server platform would look like, I'd make crash take a couple of required arguments, like a unique error code and a message to the future triager of the error about what they should do with it. That would guarantee a standard format of crash messages appearing in some automated bug tracker.
I wouldn't want to have to provide all those fields for a crash in a simple CLI script though.
That makes me wonder if it should be left up to the platform to provide a crash-equivalent, and if so decide it's name, arguments, exact behavior, etc.
Agus Zubiaga (Oct 07 2024 at 16:55):I don’t know if we need error codes. Isn’t the stack trace enough?
Agus Zubiaga (Oct 07 2024 at 16:57):Error codes seem more useful for known conditions, but you should model those with Result
Kasper Møller Andersen (Oct 07 2024 at 19:20):Having an error code makes it much easier to correlate if you have the same crash going off multiple times and your logs are sent to a central repository. In that case, the stack trace may be different for each crash for example.
Jasper Woudenberg (Oct 07 2024 at 19:23):I realize that crash should ideally only be used in unreachable branches, I think in practice we sometimes get it wrong and the result might be a bug of a crash getting reported to some error tracker, say Bugsnag.
One thing I've noticed with error trackers is that it's tricky to group related errors because there's no stable identifier.
crash, because there's no other place where you can stick metadata.That's why for a web server, I would ideally require every crash to get a unique error code, to have an explicit grouping identifier. But I definitely don't want to make the cash it should be required for every platform, that's why I wonder if it's a reasonable thing for the platform to want to define.
update: While I was writing this Kasper just said the same thing much more succinctly :).
Kasper Møller Andersen (Oct 07 2024 at 19:38):One pattern we use at work is to also have a unique ID for a crash occurrence. So when a crash happens, and a user gets an error message in the UI, that error message includes this ID. The ID is attached to the related log message as well, so if the user wants to open a support ticket, they can describe the problem from their point of view and connect it to the relevant logs.
Richard Feldman (Oct 07 2024 at 19:56):if it's automatically generated, the platform can definitely do that
Richard Feldman (Oct 07 2024 at 19:57):e.g. the platform could ask the application author to provide a function like onCrash : U64 => Response and then it will call that if your request handler crashes, passing the unique ID it generated, and then you can just do your error reporting and respond with a 500
Last updated: Jun 16 2026 at 16:19 UTC