[swift-users] "business applications market" flame
Don Wills
don.wills at portablesoftware.com
Fri Jan 8 17:01:02 CST 2016
My particular situation was a conversion from Java. There are about 10 different add() methods with different parameters in its containing class. Only one of the add() overloads could cause a RuntimeException. In Java, we use a subclass of RuntimeException as the ReallyBadError indicator that is catchable near the top of the call stack, and possibly recoverable, such as by restarting a thread. The problem is that the calling code is spread across dozens of classes in several different products. Trying to figure out which of the add calls need to be enclosed with this:
do {
try add()
}
catch()...
is a giant hunt for needles in a haystack, and even if we could find them all would be a maintenance nightmare.
The fact that I bumped into this situation converting a bunch of code from Java is irrelevant. The programming language feature I desire (unchecked thingies that unwind the stack until running into a relevant try/catch) is simply absent in Swift.
Here is a more in depth description of why that feature is important. I need a non-checked <whateveryoucallit> for the *almost* fatal situations that are recoverable at a very high level. NullPointer is the prime example of a non-checked exception in Java. Letting the programmer write code that decides how to deal with such a situation is all I want in Swift. Unfortunately, assert() is irrelevant to the problem and fatalError() is not acceptable. The server needs to stay up, even in the face of latent bugs causing NullPointer exceptions and user-defined versions of similar errors.
The Swift requirement that all throw <struct> statenments must be declared with "throws" in the containing method s a real deal killer for big APIs that want to provide the option for the programmer to build some type of recovery mechanism.
Specifically, the “Use this function to stop the program..." approach you suggest is simply unacceptable. I can't live with the *entire* program to stopping. Think of a program such as Apache Server and you will understand what I'm talking about.
> On Jan 8, 2016, at 3:28 PM, Rob Mayoff via swift-users <swift-users at swift.org> wrote:
>
> Why are you even using throw and try-bang here? It looks like, instead of throw, you should be using preconditionFailure: “Use this function to stop the program when control flow can only reach the call if your API was improperly used.”
>
> https://developer.apple.com/library/ios/documentation/Swift/Reference/Swift_StandardLibrary_Functions/index.html#//apple_ref/swift/func/s:FSs19preconditionFailureFTKT_SS4fileVSs12StaticString4lineSu_T_ <https://developer.apple.com/library/ios/documentation/Swift/Reference/Swift_StandardLibrary_Functions/index.html#//apple_ref/swift/func/s:FSs19preconditionFailureFTKT_SS4fileVSs12StaticString4lineSu_T_>
>
>
> On Thu, Jan 7, 2016 at 4:33 PM, Don Wills via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>
> func add(p1: String, _ p2 Any) {
> try! addWithThrows(p1, p2)
> }
>
> private func addWithThrows(p1: String, _ p2 Any) throws {
> // code that handles many types for p2, followed by return for each of the valid types
> throw Exception("Invalid type") /* for those types not supported which is a programmer error */
> }
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160108/6608f5a6/attachment.html>
More information about the swift-users
mailing list