Reminds me of early in my career as I was struggling with turning errors in my code into useful messages to the user. I thought exceptions were so cool and that I could just pop them up the stack and voila `print(err.msg)`.
It took me awhile to realize that good error reporting was part of the UX as much as any other feature I wanted to create for users, and that it deserved a seat at the table of the API interfaces.
I think handling timeouts properly is exactly the same case; like TFA mentioned, there is no such thing as a safe/general way to externally terminate a thread of execution. If you want timeouts to be part of your UX, you need to build it just like any other feature.
>general way to externally terminate a thread of execution
There's really no safe way to cover all cases unless you create a really scoped down interface that are explicit in what they do.
One use case might allow abrupt interruption with no cleanup (like in the case the OS is powering down) and another interrupt it might be imperative to cleanup (a long running program that can leak resources)
It took me awhile to realize that good error reporting was part of the UX as much as any other feature I wanted to create for users, and that it deserved a seat at the table of the API interfaces.
I think handling timeouts properly is exactly the same case; like TFA mentioned, there is no such thing as a safe/general way to externally terminate a thread of execution. If you want timeouts to be part of your UX, you need to build it just like any other feature.