"You've done all this work, but you haven't actually addressed any of the exceptions that you will need to handle." - The project I'm part of, is in its early stage. But I've already encountered some ways in which an error object was used to communicate failures... like requestAuthorization(options:completionHandler:)

"Swift's exception handling is based on Objective-C's error handling. You are expected to avoid even the possibility of things like out of bounds, division by zero, etc." - thanks, this really changes my perspective. Other platforms provide mechanisms to handle such exceptions.

I'm not trying to do anything complex. If the signal handler is invoked with a signal like SIGSEGV or SIGBUS, then there's nothing much to do but to log some diagnostic info and set the default signal handler, which terminates the process. If the signal handler is invoked with SIGINT (This happens when user launches GUI app from terminal and pressed Ctrl/Cmd + C), then I want to ignore it. This is just a contrived example, but would need to think about other relevant signals and actions

And when I encounter a Swift function that throws, then Swift's try and do-catch should be used. Errors like nil references should be handled using Optionals, which are unwrapped carefully using guard-let, if-let and nil coalescing operator. In this way, all possible exceptions/errors except for programming errors, can be handled in Swift. Is my understanding, right?

Quoting from your other post - "Swift has no facilities for dealing with language exceptions. The exception-like mechanisms you see in Swift are actually syntactic sugar on the Cocoa error facilities (more on that below)". Question: So, the errors I've mentioned in this post, like, - Array's out of index, division by zero etc... there are no ways to handle these kinds of errors, which are programmer bugs, in Swift. Is that right?

Thanks for the response. I've gone through your other post have some clarifications. "Catching machine exceptions is super hard and it only makes sense in very specific circumstances, for example, when you’re working on a language runtime" - I was able to capture these machine exceptions (I've only tried with 2 signals, not all) in C++ using Signal handler mechanism. Is that okay?

Thanks for confirming. What about the roadmap? Will there be 64-bit AppleWatches with 64-bit pointer sizes (basically, an arm64 AppleWatch) in the future?

How is that an improvement? Unless you click 'Trust', the AppleWatch won't be shown in the list of devices in the destination, right? And once trusted, we need to enable developer mode, which is another big headache as the button rarely appears.

I created a new empty project manually, created a class conforming to UNUserNotificationCenterDelegate and implemented this method - I don't get any warnings. But in a cmake generated project, I get these warnings. The above warnings are in a cmake generated Xcode project (apologies for not mentioning). But any idea what could be the difference?

Example please? I didn't understand why this will be needed - "Sometimes, arranging the "plumbing" to get from your App Delegate to the place where the notification is needed can be tedious".