I think the perspectives
-
“This is essentially exception handling, but done right, so we should use the accepted terminology for it which people are already familiar with”, and
-
“The primary connotation of ‘exception handling’ from other languages is that it is bad, so we should avoid reminding people of it at any cost”
are both valid in their own way, apparently irreconcilable, and we could probably continue bikeshedding on this basis until the End of Time.
(Compounded by the fact that the defining characteristics of what counts as “being exceptions” also varies from person to person.)
My own view is that what we have is manually propagated exceptions, and that using unfamiliar vocabulary (keywords) is a larger cost in terms of the “language strangeness budget” than re-using widely adopted vocabulary in slightly different ways, and that therefore we should use either catch or try here, but YMMV.
I think it’s notable that other languages “with exceptions” also have very different formulations of the idea amongst themselves, and that they use the usual “exception handling keywords” in wildly different ways, so I don’t think we’d be very much out of line with this; if anything, we’d just be following tradition.
(For instance, Swift uses try to mean “this code, unlike other code, may throw exceptions, and they will be propagated”; unlike Java, which uses it to mean “this code, like all other code, may throw exceptions, but here they will be intercepted”.)