Incidentally, I am still waiting for a language that has a way of agreeing how exceptional conditions are handled across module boundaries. I don't believe exception handling is good enough
Conversation
What I want is a standard idiom where actual errors like "invalid parameters" and exceptional-but-expected conditions like "file not found" are handled within the same mechanism, yet the mechanism understands one is lighter-weight and must be easier to do casually than the other.
1
3
Sometimes tries to convince me this is what common lisp "conditions" are but i still haven't gotten around to learning how this works.
2
3
Rust used to actually have conditions for stuff like IO errors, but having three different ways of doing error handling in one language was a bit much (results, panics, conditions). could probably elaborate…
2
2
Perhaps if the only way of handling errors was conditions then folks would have learned it properly and liked them, but at the time they were always this 'annoying backwater that you had to deal with when doing IO'.
1
Here's a broken reddit link to a now dead page: reddit.com/r/rust/comment - would need to do more digging to find it - possibly in the git repo.
1
cc. - interesting thread here - know of any good ways to get to ancient Rust documentation?
3
Off the top of my head the way back machine to see an old site as it was. Depends on how far back. If it's code based comments it might be in the git repo. You want what's from the Reddit thread? I'm like in transit right now so digging things up will be difficult till later
1
Nice! :)
1
More Rust history here:
Quote Tweet
Replying to @mcclure111 @brendanzab and 3 others
Yeah, there's also a question of how much you want to be imposing a fluid-binding construct (which usually means twiddling global lists in TLS on handler boundaries) on everyone. The more people tended towards "chase C++ perf" the less desirable fluid conditions looked.