Nasin depends on objects. It would be cool to, instead of crash to stderr or whatever go normally does, throw up an error dialog explaining the error when something panics within RunApplication. This would indicate to the user that something has gone wrong with the application instead of just abruptly closing it. When the user presses OK to close the application, we can re-panic to still have the normal behavior.
Nasin depends on objects. It would be cool to, instead of crash to stderr or whatever go normally does, throw up an error dialog explaining the error when something panics within RunApplication. This would indicate to the user that something has gone wrong with the application instead of just abruptly closing it. When the user presses OK to close the application, we can re-panic to still have the normal behavior.
Because application code is either run in callbacks (executed in the backend's event loop), or in a separate goroutine, nasin would have to re-initialize the backend to recover from the application panic (when the panic can even be recovered from).
If there is ever a desktop environment built with Tomo, this feature could be implemented as a wrapper program that watches for program crashes and stack traces and displays them to the user once they happen.
On second thought, this would not work at all.
Because application code is either run in callbacks (executed in the backend's event loop), or in a separate goroutine, nasin would have to re-initialize the backend to recover from the application panic (when the panic can even be recovered from).
If there is ever a desktop environment built with Tomo, this feature could be implemented as a wrapper program that watches for program crashes and stack traces and displays them to the user once they happen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Nasin depends on objects. It would be cool to, instead of crash to stderr or whatever go normally does, throw up an error dialog explaining the error when something panics within RunApplication. This would indicate to the user that something has gone wrong with the application instead of just abruptly closing it. When the user presses OK to close the application, we can re-panic to still have the normal behavior.
On second thought, this would not work at all.
Because application code is either run in callbacks (executed in the backend's event loop), or in a separate goroutine, nasin would have to re-initialize the backend to recover from the application panic (when the panic can even be recovered from).
If there is ever a desktop environment built with Tomo, this feature could be implemented as a wrapper program that watches for program crashes and stack traces and displays them to the user once they happen.