> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
