In Java there is a hierarchy of errors, the idea is that you catch at different severities. It isn'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!
In Swift this general concept of user defined error type which have a severity level could be implemented, it might be:
protocol ProgramFatalError {} // Not possible to catch - terminates program
protocol ThreadFatalError {} // Not possible to catch - terminates thread, but calls thread's deinit - deinit has access to the error
protocol Error {} // As is
How does TheadFatalError is supposed to behave in a world dominated by queue ?
···
Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution <swift-evolution@swift.org> a écrit :
In Java there is a hierarchy of errors, the idea is that you catch at different severities. It isn'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!
In Swift this general concept of user defined error type which have a severity level could be implemented, it might be:
protocol ProgramFatalError {} // Not possible to catch - terminates program
protocol ThreadFatalError {} // Not possible to catch - terminates thread, but calls thread's deinit - deinit has access to the error
protocol Error {} // As is
Server side code often spawns a thread per connection. The idea of
ThreadFatalError is that a thread is the 'unit of code' 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.
Since exactly what Swift will support in terms of concurrent programming is
to be debated it may not be a thread that is the 'unit of terminable code',
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.
For example it may be possible to have just two levels: Error that is
potentially user recoverable and ThreadFatalError that terminates the
'terminable unit of computing' and if the top 'unit of computing' receives
a ThreadFatalError it terminates the whole program and hence
ProgramFatalError is not required.
As an aside: thread per connection and hence ThreadFatalError was an
example given at the start of this discussion thread [pun intended].
···
On Sat, 21 Jan 2017 at 10:35 am, Jean-Daniel <mailing@xenonium.com> wrote:
> Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> a écrit :
>
> In Java there is a hierarchy of errors, the idea is that you catch at
different severities. It isn'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!
>
> In Swift this general concept of user defined error type which have a
severity level could be implemented, it might be:
>
> protocol ProgramFatalError {} // Not possible to catch - terminates
program
> protocol ThreadFatalError {} // Not possible to catch - terminates
thread, but calls thread's deinit - deinit has access to the error
> protocol Error {} // As is
How does TheadFatalError is supposed to behave in a world dominated by
queue ?