You need to list all exception types that can be thrown. And when you call another throwing method without handling the exception, it needs to be listed as well. Which means that you can end up with a method that has a list of a dozen of exception names that can be thrown.
> On Dec 27, 2016, at 11:56 AM, Derrick Ho via swift-evolution > <swift-evolution@swift.org> wrote: > > Daniel Leping, I am unfamiliar with java. Do you have any resources that > describe the nightmare in detail? > On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> > wrote: >> -1 for specifying errors for throws. Please don't. Proven by practice in >> java it's a nightmare. > > In Java, this topic is really interesting: > It sounds like a great idea, but in real-life situations, afaics everyone > hates checked exceptions. > > But Swift isn't Java, and our error handling is different from most > established languages, so imho we shouldn't base that decision on experiences > from other models only: > I don't see downsides, because you already need "try" for everything that can > throw, and afaics, it would be easy to ignore the information that only a set > of exceptions can happen in a given context. > > So, imho before there is a decision wether "throws" should be moved, the > possibility to annotate it with a fixed set of error types should be either > abandoned or incorporated. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
