Yes it is (and i saw what yo did here ). And i see your problems with using "already" established names for "things" that would impose other semantics in Rust by using it. But i also lean to the sentiment of "It does not matter as long as it leads the user into the right direction although its not a correct substitute in detail".
Your argument against catch is, that it is used in other languages in the context of exceptions with a different semantic. But it is within the domain of error handling. So being opposed to every term that was ever used elsewhere which has a different semantic is very limiting and also not exhaustive (nobody knows every occurrences etc. and where do we draw the line between popular/unpopular if we decide to reuse unpopular ones) which could be a worse trade off of reusing an established term but with a different semantic but within a certain domain. You see, you liked maybe (i do too) but are limiting yourself to not like it because Haskell is using it in a different way semantically. The question here is at which point it does not really matter? try, catch, maybe (to choose some) are good candidates and to be honest i have no problem with catch because even though it is used in many other languages for a different thing semantically it is easy for most of the programmers out there to associate this term with error handling – and that might be enough to reduce mental overload. If i see catch { .. } with a minimal example i claim that more beginners understand AND remember what this means and how to use it opposed to a term like trap etc. which they never saw in any other programming language and their brain is not wired to that term belonging to the domain of error handling. I imagine people sitting in front of the monitor wondering "what was this weird keyword again to stop propagating errors .... lets consult documentation"
TLDR; I see your problem with reusing terminology in semantically different contexts BUT i think it is unnecessarily increasing mental overhead to use terminology not very popular in current programming languages! And i hope your struggle with maybe (which might be a good candidate) is self evident here?
There’s a bunch of stable functions with try_ prefix already, so I think in Rust’s context it already has an established meaning. Change to a different keyword not related to try/catch would have to deal with the dilemma of either duplicating these functions for consistency or still having try/catch-related names and naming inconsistency.
Whether similar-but-not-quite-same features should have same or different names is context dependent:
“traits are like Java interfaces” is actually a very helpful explanation to novices who try (and fail) to do OOP in Rust. Even though traits in some ways aren’t like interfaces, it sets close-enough frame of mind to get started.
Rust’s enum is different from C’s enum, but it doesn’t cause confusion.
“References” on the other hand are suuuper confusing to C++ programmers who expect them to be usable like regular pointers. I’d prefer &/&mut to be called something completely different, like “read permission”/“exclusive read/write permission”.
A heads up: I’m currently in the process of writing an RFC for the keyword reservation of keyword { .. } block expressions. I will probably be done with it today.
Interesting. At the risk of creating a tangent, I'm usually biased toward the C++ model of programming reality, and I always found "references" to be an extremely intuitive and broadly accurate term. To me the biggest difference between C++ references and Rust references is simply that Rust tries a lot harder to provide some basic semantic guarantees for them, e.g. that they even have a referent so it's safe to dereference them.
(Not that this affects your general point that "Whether similar-but-not-quite-same features should have same or different names is context dependent." Of course I agree with that)
To me using unknown keyword would be confusing. if, enum, and for does not operate the same way in Rust than in most languages I know, but I am happy they where not renamed because their intent is pretty much the same.
Likewise the intent of try block is pretty much the same than in languages with exception. As a beginner, faillible, maybe or trap, would have been puzzling for me. Using Result values instead of exception is a technical detail I will have to learn anyway as soon as I will need to use them.
Just as an apparent minority in this thread, I’d like to voice my support of the catch keyword.
My only confusion with these blocks was never what they do, but only why one would use them. My thinking roughly was: “If catch { func()? } is the same as func(), why would I even need these blocks?” This type of confusion, i think, is best addressed by documentation.
Regarding confusion with exception-based error handling, I think the chances are rather slim for one simple reason: The syntax is different. The catch clause in languages using exceptions always require an exception type to be specified, whereas the Rust catch block needs no further annotation:
I also don’t share the sentiment that the meaning of catch blocks were unintuitive for people not having a background in exceptions. I interpret this block as “catch any errors that might occur in this block and continue after it”, which seems rather straight-forward to me.
In summary, I think that catch catches* the meaning of the block rather well and that fears of confusion with constructs from exception-based error handling are not unfounded, but disproportional. Most of the alternatives suggested in this thread are also okay, but their novelty might be off-putting to new learners of Rust. Among them, I think I’d prefer try, fallible, and trap the most. (resultof seems too unrelated to error handling at all.)
Based on this criteria I think only trap and catch are
left because:
try:
+ on intuitive understanding (similar to other languages)
big - on intuitive understanding (to similar to other languages,
it’s likely users would expect a catch block, and wonder why it
doesn’t handle panics)
fallible:
+ on not overlapping with exception handling terminology
big- as it’s derived from Failure which currently is kinda
coined as a specific kind of error type which is static and
has a backtrace (Failure crate). Also even without the failure
crate I would use failure as a word for a more serve error, through
maybe I’m alone with this?
- due being long and easy to confuse in it’s spelling
(falible, failible faillible ?? ), this might sound off-topic but for
anyone which has trouble with spelling and isn’t a native english
speaker this is a (potentially) big think
catch:
+ on intuitivity (similar to other languages)
at the same time different enough to be less likely to
be confused, so no - here
trap:
very small + on intuitivity, trapping errors is used in some
context (mainly where errors are signaled). It’s also a word
similar to catch.
+ on not overlapping with exception handling terminology
small - on overlapping with signal handling and in extension
of this hardware exceptions, but I think as rust works at a different
abstraction level this should be fine.
resultof
+ for explaining what it does (you get the result of the following
blog)
small - for being more than one word
small - for not being in the rust naming schemes (which
would be result_of or ResultOf, which in turn would get
be big - for looking like a function/type but definitely not like a
keyword)
[EDIT] maybe:
- on not being intuitive at all, catch-block does give you
the result of the following block of code, not maybe a result,
Through you could say it maybe gives you an error or maybe an
item and merges this into a singe result returned. (I personally
would guess maybe is an alternate form of an option, or that
it maybe executes the following block on code depending on some context).
+ on not overlapping with exception terminology
Personally I think I would go with catch or trap, basing the
decision on how much I want to distance it from traditional
exception handling.
And I thinks both failible and try are a bad idea.
You mention try may be confusing that it doesn’t catch panic!(), but I come to the opposite conclusion:
try {} blocks are similar to try_ functions: try { foo() } ≈ try_foo(). The existing try terminology in Rust is not related to panics at all, but already has plenty of uses related to result wrapping
There is already panic::catch_unwind(|| {}), so “catching” in Rust already refers to panics. It wouldn’t be unreasonable to think that catch {} is a syntax sugar for panic::catch_unwind(|| {}).