[swift-evolution] Move placement of 'throws' statement

[Rod Brown]

I have rarely caught up into these situations - if I end up with multiple types of error, I generally create a wrapper error type. For example, my networking code includes a NetworkError type which encompasses all the errors that can happen within Foundation or my own code.

Could we not then in this way limit it to one declared type, to simplify the system? And then if you really don’t want to document type type, you either put:
> func myMethod(args:[String:Any]) throws Error { … }

Or:
> func myMethod(args:[String:Any]) throws { … }

As we currently do anyway?

How can giving more information at least optionally for safer and more correct code be a bad thing?

- Rod


> On 27 Dec 2016, at 11:21 pm, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Daniel Leping, I am unfamiliar with java. Do you have any resources that describe the nightmare in detail?
> 
> I think the problem really comes down to the inflexibility of it; if you specify X, Y, and Z as throwable types, then all code calling that method must handle those types in some way.
> 
> Thing is, I wonder if this would be as much of a problem for Swift? We have the try! and try? variations which make it very easy to ignore/simplify error handling if we don't expect any to occur at all, or it doesn't matter if they do, and we have the same basic means of handling generic unknown (or unhandled) error types, plus throws and rethrows.
> 
> Part of the problem is that Java only ever treats the specified types as mandatory (you *must* handle them somehow); I think a more elegant solution could be if we could somehow mark them as optional, for example:
> 
> 	func myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
> 
> Here myMethod can throw two error types, IOError and IllegalArgumentError, but while the first *must* be handled somehow, the latter is only optional as a well formed args dictionary cannot possibly produce an error, i.e- it's an error you might only want to check if the args dictionary was built dynamically.
> 
> Basically in this case not handling an IOError would be an error, while not handling IllegalArgumentError would be a warning (with some way to suppress it). This means that APIs could even add new error types so long as they are optional, though it's not advisable.
> 
> In addition to this we might introduce some mechanism for specifying *some* of a method's error types, for example:
> 
> 	func myMethod() throws IOError… { … }
> 
> Here myMethod specifies an explicit IOError that *must* be handled, but also indicates that there are other, optional, types that don't need to be handled explicitly. The idea here is that you specify only the most important types, but can still indicate that there are other possible types (but maybe they're rare, or only occur in very unusual circumstances described in documentation), or you just want to leave the definition open-ended.
> 
> So yeah; personally I'm a supporter of being *able* to specify thrown types, but do think it needs to be more flexible in what and how we specify them, to avoid falling into the same pitfalls as Java. I definitely think that being able to specify types that *must* be handled is useful, though we'd need to make clear best practice (i.e- mandatory type handling should be reserved for more serious errors in most cases).
> 
> Other things to consider are wether explicit thrown types could be marked as handle immediately (i.e- throwing the error up the chain is a warning), and whether non-explicit throws/rethrows could be automatically computed. For example, if I have a method that has a plain throws, and handles three methods, throwing errors of A, B? and C… respectively, with the first called via try?, then my method's throwable types are B?, C…
> 
> 
> To conclude; while I like Swift's error handling as-is it's mostly because I tend to use try! and try?, but when it comes to an actual try/catch I do like Java's compiler supported enforcement making sure that I'm aware of which types I'm supposed to do something with.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/ddff0850/attachment.html>