> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution > <[email protected]> wrote: > > I really hate to bring Java up, but I really do think it got at least one > thing right with its error system, namely that one subset of error (namely > `RuntimeException`), wouldn't be enforced by the compiler, but could > optionally be caught.
I don’t entirely agree for two reasons: 1. If a runtime error is thrown and caught, there is no way to guarantee the logical consistency of the state of the running process because who knows which stack frames were unwound without cleaning up properly. There is no way to safely catch a run time exception and recover. 2. People abuse RuntimeException to simplify their error handling code: “if I throw a RuntimeException I don’t need a zillion catch clauses or throws declarations”. Furthermore, if a library uses RuntimeExceptions where it should be using Exceptions there is no way to know if its API has changed except by reading the (hopefully up to date) documentation. Problem 2 makes me particularly bitter because JEE programmers seem to have learned that allowing code to throw null pointer exceptions has no real consequences for them so they become very cavalier about doing their null checks. The user sees an 500 error page, the sys admin gets a 200 line stack trace in the log, but the system carries on. If you are lucky enough to have the source code to diagnose the problem, it usually turns out that the exception was thrown on a line with eight chained method calls. When you do track the problem down, it turns out you forgot a line in the properties file or something similar but the programmer couldn’t be bothered to help you out because it was easier just to let the null pointer exception happen. I like Swift’s error handling because programming errors (like force unwrapping nil) are punished mercilessly by process termination and errors caused by external factors cannot be completely ignored. You have to at least put an empty catch block somewhere. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
