If you want improved error handling, feel free to put together a proposal once Swift 4 phase 2 is over. A good proposal should take into account the reasons Swift's error handling was designed as it currently is (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst <https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst>)
Otherwise, if you really need to build a web server framework that can swallow any sort of application logic without choking, perhaps Swift as it currently stands isn't the best tool for the job. Best, Austin > On Mar 12, 2017, at 12:06 PM, Elijah Johnson <ejrx7...@gmail.com> wrote: > > The problem for using Swift on the server is one of these optionals (or array > index out of bounds error, or cast from Int to UInt error) would crash the > entire server directing many requests. Granted, thats not Apple’s busininess, > but it is pretty much standad in a modern webserver never to crash, and > whoever is developing servers will find they don’t have the necessary power > to do that. Some languages like PHP have a unique process per-request style, > but that phrohibits shared data. One could do the same with Swift, but it > would be a major loss. > > Just because Swift is not garbage collected doesn’t mean that you can’t > safely unwind the stack and continue execution somewhere. If “bad” developers > would start using this as unwanted exceptions, then it can be made inconvient > somehow. > > Think about a server that handles 1,000 requests per minute - its going to > happen evenutally, even despite testing, and chances are that once it happens > it will re-occur - and now the server goes down every minute or even every > few seconds and needs an auto-restart loop. > > If we’re going to be talking about “bad developers” as in ones who might once > code a bug with an optional or index out of bounds exception, then that is > going to be a very high standard and result in a very mild adoption of server > side Swift. Maybe it would take off for a while, and then when people realize > these things, they will say “thats why everyone writes their server-side code > in Java/C#/PHP, etc” and Swift will be a thing for people who need ultra-fast > performance on a server. > > Its not really Apple’s business, and clearly you are trying to replace only > C++ and not Java/C#, but if you can add a compiler mode with exceptions > instead of fatalError(mesage:) calls, that would contribute a lot to making > web servers with Swift. Even if you leak the entire call stack, it would > still be better than crashing an entire web serer. > > > On March 6, 2017 at 9:47:03 PM, Austin Zheng (austinzh...@gmail.com > <mailto:austinzh...@gmail.com>) wrote: > >> Swift already is an unmanaged language, and is far closer to C++ than Java. >> There is no equivalent to the CLR or JVM and it is trivially easy to call >> into C code or the unsafe APIs and do nearly anything that C can do with >> regard to direct access to memory. >> >> The force-unwrap operator was never intended to model a Java-style runtime >> exception. Instead, it is an assertion which indicates a programmer logic >> error. The preferred way to handle an optional at runtime has always been to >> use the conditional-unwrapping functionality the language offers. The >> correct way to report errors at runtime that aren't due to programmer error >> is through the do-try-catch mechanism. Pervasive, unnecessary use of '!' is >> a project management and/or developer competence issue, and not something >> the language should go out of its way to fix. >> >> Sugaring 'if let' for programmer convenience is something on the commonly >> rejected proposals list: >> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md >> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md> >> >> Regards, >> Austin >> >> >> On Mon, Mar 6, 2017 at 6:27 PM, Elijah Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Additionally, not discarding previous comments, one way the language could >> be improved is by replacing (or rather augmenting) optional binding with a >> faster syntax. >> >> ex. >> >> func test( name : String?, name2 :String? ){ >> name! , name2! { >> // inside this block, “name” and “name2” are non-optional >> } else { >> // no forced unwrapping, just optional else case >> } >> } >> >> Whereas the alternative (current optional binding), requires a re-definition >> of variables and an additional “if” operator. Besides the extra characters >> involved in typing and reading it, usually variables have specific names >> that the user does not want to augument. >> >> func test( name : String?, name2 :String? ){ >> if let nameUnwrapped = name , let name2Unwrapped = name2 { >> >> } else { >> } >> } >> >> func test( name : String?, name2 :String? ){ >> guard let nameUnwrapped = name , let name2Unwrapped = name2 else { >> >> } >> >> } >> >> The fact that we don’t need a “nameUnwrapped” variable (which is unsightly >> and requires refractoring) is one thing that still makes forced unwrapping >> still very much a necessary or common part of Swift coding, even where it >> could be replaced with optional binding. >> >> >> >> >> On March 6, 2017 at 7:20:40 PM, Elijah Johnson (ejrx7...@gmail.com >> <mailto:ejrx7...@gmail.com>) wrote: >> >>> Hi, >>> >>> I’ve been recently considering Swift on the server-side, and there came up >>> the question, “what happens when a null optional is forcibly unwrapped?” >>> and the answer was clearly that not only would the request crash, but the >>> entire server would also crash, since the server itself is/would be also >>> written in Swift. >>> >>> I think that this highlights serveral weaknesses in Swift’s “null safety” >>> attempts. The first is that there needs to be a way to isolate blocks of >>> code so that a “null pointer exception” does not crash the system. I think >>> it is fair to say, in the language of Java, that these are really “runtime >>> exceptions” and for some reason are being treated as segmentation faults >>> would be in C/C++. In my opinion, the existence of these things has the >>> ability to bring Swift down below Java and closer to an unamanged language. >>> Not really sure why it would ever be desireable, but in terms of >>> server-side programming, it is definitely a serious issue. >>> >>> Secondly, Swift’s “null safety” is really completely undermined by these >>> “force-unwrap” errors. I agree with the usage of new language features like >>> guard, optional binding, etc to remove a null value, but I see this >>> force-unwrap as extremely pervasive for a lot of reasons: >>> >>> 1. When porting code from a C style language to Swift, force-unwrap is >>> needed to make the code work without refractoring. >>> 2. XCode itself reccomends this operator and when it is used to satisfy a >>> requirement, then it can be left in the code >>> 3. Some styles of coding just can’t work without force-unwrap. >>> >>> I don’t think the logic of making the consequences extreme for making a >>> mistake are a rational for making better coders. In fact, I personally see >>> the “force-unwrap” operator having very great potential usage as a >>> deliberate assertion exception - the programmer demands that a certain >>> value be non-null for execution to continue, only there should be a proper >>> scope and context where these exceptions can propogate to. On debug modes, >>> one might want it to pause on the line, but for other uses, it should be >>> caught IMO - on regular code by the user, and inside dispatch blocks by the >>> queue itself. For a multithreaded app or server to exit, the user should >>> have to explicitly write exit(0), isn’t this the goal of a managed >>> language? Maybe in some cases, Apple will want the program to crash, but if >>> Swift is given an audience not just with Apple hardware, then it should >>> have more flexibility IMO. >>> >>> Elijah >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
