0

Please correct me if I'm wrong, but from what I understand with Swift 2.0 Apple really encourage you against having many catch statements to handle different error types. Instead in most cases your do-catch block would have only one catch statement that catches everything.

I'm not saying that this is a good or bad idea. But I just don't see any other option. You can't be 100% sure about error type that you may or may not receive after a function call. This is because there is no way to specify a list of possible errors in a function definition after "throws" statement. So you would need to dig into the call stack of the function to find this out. And this could be a very deep stack... Will anyone actually do this every time just to get the idea what to catch?

To demonstrate what I mean:

func funcA() throws { 
    throw SomeError 
}

func funcB() throws {
     if something {
         throw OtherError
     }
     try funcA()
}

func funcX() throws {
     try funcB()
}

Now I if I want to call funcX - I don't really know that it can throw SomeError or OtherError by looking at funcX definition. In order to find this out I will need to go and review the entire call stack tree from funcX. While it doesn't look too complex in the extremely short example above. But in a real world source code this may become an issue.

pnuts
  • 58,317
  • 11
  • 87
  • 139
Illya S
  • 161
  • 1
  • 12
  • Why do you post here as a question what you've posted [here](http://stackoverflow.com/a/32762705/2227743) as an answer? – Eric Aya Sep 24 '15 at 13:49
  • I started it as an answer, but then realized that this is quite an important topic for a dedicated discussion. I will probably delete the previous one (answer). – Illya S Sep 24 '15 at 13:54
  • Indeed, in this case it's better to delete the one posted as an answer. Thanks for clarification. – Eric Aya Sep 24 '15 at 13:55
  • 3
    "Apple really encourage you against having many catch statements to handle different exception types." First, we're catching errors, not exceptions. Second, why do you say that? Do you have a reference for that claim? If you look at the [Error Handling](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html#//apple_ref/doc/uid/TP40014097-CH42-ID508) section of _The Swift Programming Language_, their example includes multiple catches. – Rob Sep 24 '15 at 14:02
  • Ok, lets call them errors (exception is just a very similar concept from other languages). Yes, I saw that Error Handling section. And I'm not claiming that it is not possible to have multiple error types. I'm saying that it is not practical in a more or less big project where an error may pop up from a deep call stack. So when you call a function that may throw an error you can't say for sure what error types to expect without analyzing the entire tree of possible calls from this function. – Illya S Sep 24 '15 at 14:20
  • Or am I missing something? I.e. in Java you can actually see the list of exception types that a function may throw just by looking at the function (method) definition. – Illya S Sep 24 '15 at 14:31
  • 1
    I tend to agree with @ElyaS .. I wouldn't say they recommend this or that - but you have to know what to expect. But whats the issue? Handle what what you can handle and know, the rest throw out ;) -- it always worked with NSError and the new syntax is basically only syntactic sugar for that... seems ok to me – Daij-Djan Sep 24 '15 at 15:17
  • @ElyaS - Re error v exception, yeah, I get it, but I only clarified the difference because we have to deal with _both_ in Cocoa, so we don't want to conflate the two. Thanks for fixing. Re `catch` statements, as djan-djan says, you just add `catch` statements for whatever unique error handling logic you app needs. If you don't have/need multiple logic paths for error handling, then have single `catch`. If you need to handle different errors differently, then use multiple `catch` statements. But sadly, yes, it is the programmer's responsibility for knowing what sort of errors may arise. – Rob Sep 26 '15 at 01:02

0 Answers0