-
-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleaning up after tcell on panic #147
Comments
I don't think there is a good solution to this. You have to run some code to send the terminal handling ioctls, and I have no idea how to do that other than a defer or explicitly running the Fini code. |
We need the logical equivalent of atexit() I guess, but with a panic(), you're already aborting in an unusual manner, so even atexit() is not necessarily gonna do the trick. I discourage the use of panic() for "ordinary" cases -- this function should only be used when some critical programming error has been found. |
I'm gonna close this. Its not really something we can fix. Restoring terminal settings requires us to have code that runs -- and really there isn't a better way to do this than to arrange for the defer s.Fini() call. You should try hard not to panic(). If you're encountering panic(), then you need to fix whatever bug is causing a disorderly crash, instead of trying to make the panic() situation "nicer". |
Consider the below code:
When run:
Because the panic is in a goroutine, the deferred
s.Fini
call on line 11 is never executed. However, if the call tos.Fini
is never made, then the terminal is left in a funky state following the run of the program (see above).Other than adding a
defer s.Fini()
in all goroutines in a whole application, how can I successfully clean up after tcell when any goroutine panics?The text was updated successfully, but these errors were encountered: