-1

Before you relieve the itching in your fingertips, I already understand:

  • how and when to use the try keyword
  • the differences between the try, try?, and try! keywords

What I want to understand is what the use of the unadorned try keyword buys me (and you and all of us) over and above merely quieting a compiler diagnostic. We're already inside the scope of a do, and clearly the compiler knows to demand a try, and I can't (yet) see how there might be some ambiguity about where the try needs to land. So why can't the compiler quietly do the right thing without the explicit appearance of the keyword?

There's been a fair amount of discussion (below) about the possibility that the language is trying to enforce readability for humans. I guess we'd need the input from one of the Swift language designers to determine whether that's true. And even if we had that it would be debatable whether it's wise and/or has been a success. So let's put that aside for the moment. Does the existence of the un-adorned try keyword solve some problem other than enforcing readability for humans?

Integer Poet
  • 747
  • 5
  • 19
  • 1
    You don't write `try` for the compiler, you write it for other readers of your code. – Alexander Aug 17 '20 at 20:10
  • Given that the line of code which might fail is already contained by a `do`, that doesn't seem likely to be the reason. – Integer Poet Aug 17 '20 at 20:13
  • 1
    As you said, there's never any ambiguity for the compiler. All functions that can throw are statically marked as such, so there's "no surprises". And besides, if you forget the `try` keyword, the compiler will remind you about it. *it's not for the compiler*. A do block can have *many* expressions, and its not at all obvious which one of them is the source of thrown errors. Which one of these 3 lines throws an exception? https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/util/ArrayList.java#L859-L861 – Alexander Aug 17 '20 at 20:17
  • I'm not arguing it's for the compiler. What I’m getting at is that it doesn’t seem compellingly useful to a human reader either. Indeed there can be all kinds of things going on inside a `do`, some of which can fail and some of which cannot. One might even have multiple appearances of `try` inside a single `do`, in which case the source of potential error is ambiguous. So by itself the presence of `try` doesn’t completely solve an ambiguity problem anyway. To me it seems natural to code a `catch` as if anything (and everything) inside the corresponding `do` can fail. – Integer Poet Aug 17 '20 at 20:34
  • "One might even have multiple appearances of try inside a single do", sure, there's no silver bullets. "To me it seems natural to code a catch as if anything (and everything) inside the corresponding do can fail." And that would be incorrect, because there's plenty of non-throwing code, and to treat it all as potentially non-throwing is a) incorrect b) not useful. – Alexander Aug 17 '20 at 20:41
  • Well, to be clear, I'm not saying one should attempt to handle errors for code which cannot possibly produce them. I'm merely saying it seems natural to me that `catch` expressions treat their corresponding `do` as a monolithic source of potential error and not care about its internal details, since the language offers no way to tease them apart anyway. Really, from a style perspective, I'm inclined to put only a single statement inside a `do`; I would consider that a worthwhile effort in consideration of future human readers. But a keyword wart? Not so much. – Integer Poet Aug 17 '20 at 20:50
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/220000/discussion-between-alexander-reinstate-monica-and-integer-poet). – Alexander Aug 17 '20 at 20:53
  • Please read [Error Handling](https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html) in the Swift Language Guide. You – the developer – are responsible for proper error handling. That's a kind of homework which the compiler cannot do for you. – vadian Aug 17 '20 at 20:55
  • @vadian I don't think OP said anything at all that would suggest that he doesn't feel responsible for proper error handling. – Alexander Aug 17 '20 at 21:02

1 Answers1

1

After a long, productive discussion (linked elsewhere on this page)…

In short, the answer is no, there isn't a purpose other than enforcing readability, but it turns out the readability win is more significant than I had realized.

The try keyword should be seen as akin to (though not the equivalent of) a combination of if and goto. Although try doesn't direct the compiler to do anything it could not have inferred it should do, no one would argue that an if or a goto should be invisible. This makes try a little weird for folks coming from other languages — but not unreasonably so.

It may be difficult for Objective C programmers to grasp this because they are accustomed to assuming almost anything they do may raise an exception. Of course, Objective C exceptions are very different from Swift errors, but knowing this consciously is different from metabolizing it and knowing it unconsciously.

As well, if your intuition immediately tells you that as a matter of style in most cases there should probably be only one failable operation inside a do clause, it may be difficult to see what value a try adds.

Integer Poet
  • 747
  • 5
  • 19