<div><br><div class="gmail_quote"><div>On Sat, 21 Jan 2017 at 10:35 am, Jean-Daniel &lt;<a href="mailto:mailing@xenonium.com">mailing@xenonium.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg"><br>&gt; Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; In Java there is a hierarchy of errors, the idea is that you catch at different severities. It isn&#39;t particularly well implemented in Java with a weird hierarchy and errors strangely classified and poor naming. Despite these glaring shortcoming it does actually work!<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt; In Swift this general concept of user defined error type which have a severity level  could be implemented, it might be:<br class="gmail_msg"><br>&gt;<br class="gmail_msg"><br>&gt;    protocol ProgramFatalError {} // Not possible to catch - terminates program<br class="gmail_msg"><br>&gt;    protocol ThreadFatalError {} // Not possible to catch - terminates thread, but calls thread&#39;s deinit - deinit has access to the error<br class="gmail_msg"><br>&gt;    protocol Error {} // As is<br class="gmail_msg"><br><br class="gmail_msg"><br>How does TheadFatalError is supposed to behave in a world dominated by queue ?</blockquote></div></div><div>Server side code often spawns a thread per connection. The idea of ThreadFatalError is that a thread is the &#39;unit of code&#39; that you can terminate but leave the rest of the program running. For a server application the connection to the server is dropped when a ThreadFatalError is thrown, the connection can then be restablished because the main part of the program is still running and in particular can spawn new threads. </div><div><br></div><div>Since exactly what Swift will support in terms of concurrent programming is to be debated it may not be a thread that is the &#39;unit of terminable code&#39;, it could be an actor for example. The thread/actor may well be executed on a queue as you suggest. In particular my ThreadFatalError is not a solid proposal since it is not yet known how Swift will handle concurrency. The main point I was making is that a hierarchy of programmer defined errors is useful since some are recoverable, some only need to terminate part of the program, and others need to terminate the whole program. The exact dicing and execution model are less important than the concept of programmer-defined-granulated errors. </div><div><br></div><div>For example it may be possible to have just two levels: Error that is potentially user recoverable and ThreadFatalError that terminates the &#39;terminable unit of computing&#39; and if the top &#39;unit of computing&#39; receives a ThreadFatalError it terminates the whole program and hence ProgramFatalError is not required.</div><div><br></div><div>As an aside: thread per connection and hence ThreadFatalError was an example given at the start of this discussion thread [pun intended].</div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature">-- Howard.</div>