<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 (<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" class="">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst</a>)<div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 12, 2017, at 12:06 PM, Elijah Johnson &lt;<a href="mailto:ejrx7753@gmail.com" class="">ejrx7753@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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.</div><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div id="bloop_sign_1489343942528276992" class="bloop_sign" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><p class="airmail_on" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On March 6, 2017 at 9:47:03 PM, Austin Zheng (<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>) wrote:</p><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span class=""><div class=""><div class=""></div><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Sugaring 'if let' for programmer convenience is something on the commonly rejected proposals list:&nbsp;<a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" class="">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Austin</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 6, 2017 at 6:27 PM, Elijah Johnson via swift-evolution<span class="Apple-converted-space">&nbsp;</span><span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span><span class="Apple-converted-space">&nbsp;</span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">Additionally, not discarding previous comments, one way the language could be improved is by replacing (or rather augmenting) optional binding with a faster syntax.</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">ex.</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">func test( name : String?, name2 :String? ){</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">&nbsp; &nbsp; &nbsp;name! ,&nbsp;name2! {</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">// inside this block, “name” and “name2” are non-optional</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>} else {</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">&nbsp; &nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>// no forced unwrapping, just optional else case</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">&nbsp; &nbsp;}</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">}</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">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.</div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">func test( name : String?, name2 :String? ){</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>if let nameUnwrapped = name , let name2Unwrapped = name2 {</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>} else {</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">&nbsp; &nbsp;}</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">}</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class=""><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">func test( name : String?, name2 :String? ){</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>guard let nameUnwrapped = name , let name2Unwrapped = name2 else {</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>}</div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">}</div></div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="margin: 0px;" class="">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.</div></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><br class=""><div id="m_2492479024697317942bloop_sign_1488852857050308864" class="m_2492479024697317942bloop_sign"></div><br class=""><p class="m_2492479024697317942airmail_on">On March 6, 2017 at 7:20:40 PM, Elijah Johnson (<a href="mailto:ejrx7753@gmail.com" target="_blank" class="">ejrx7753@gmail.com</a>) wrote:</p><blockquote type="cite" class="m_2492479024697317942clean_bq"><div style="word-wrap: break-word;" class=""><div class=""><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">Hi,</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class=""><br class=""></span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">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.</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class=""><br class=""></span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">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.</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class=""><br class=""></span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">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:</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class=""><br class=""></span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">1. When porting code from a C style language to Swift, force-unwrap is needed to make the code work without refractoring.</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">2. XCode itself reccomends this operator and when it is used to satisfy a requirement, then it can be left in the code</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">3. Some styles of coding just can’t work without force-unwrap.</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class=""><br class=""></span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">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.</span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class=""><br class=""></span></div><div id="m_2492479024697317942bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><span class="">Elijah</span></div><div id="m_2492479024697317942bloop_sign_1488843525920942080" class="m_2492479024697317942bloop_sign"></div></div></div></blockquote></div><br class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></blockquote></div></div></div></div></span></blockquote></div></blockquote></div><br class=""></div></div></body></html>