Where do error messages from `panic(err) go? #114

New Issue

asdf · 2019-12-04T09:12:07Z

asdf commented

2019-12-04 09:12:07 +00:00

(As per #113)

If the client can't initialise for some reason, like if the terminal can't be set up, or if the config file can't be created, the client panics.

It seems that when the panic occurs, the error message should be displayed to the console, but it is not displayed.

(As per #113) If the client can't initialise for some reason, like if the terminal can't be set up, or if the config file can't be created, the client panics. It seems that when the panic occurs, the error message should be displayed to the console, but it is not displayed.

sloum commented

2019-12-04 16:38:15 +00:00

That is because of our defer cui.Exit() I believe. Once cui.Init() is called we are on the alternate screen buffer for the terminal. Because we use defer cui.Exit(), that is the last thing that is run....always. Which means any messaging that prints will get cleared out by exiting the alternate screen buffer.

Something that could allow for some flexibility with that while ensuring we still always leave the buffer is to add in a print statement in .cui.Exit(). That print statement can print the value of a string pointer. That string pointer can be updated in places that panic would otherwise be called. That way we still print after the switch of screen buffers.

I had thought that panic would prevent the defer from running, but I guess that is not the case?

The above proposed methodology might work out better for us anyway and provide guarantees that the terminal resumes its normal modes.

That is because of our `defer cui.Exit()` I believe. Once `cui.Init()` is called we are on the alternate screen buffer for the terminal. Because we use `defer cui.Exit()`, that is the last thing that is run....always. Which means any messaging that prints will get cleared out by exiting the alternate screen buffer. Something that could allow for some flexibility with that while ensuring we still always leave the buffer is to add in a print statement in `.cui.Exit()`. That print statement can print the value of a string pointer. That string pointer can be updated in places that panic would otherwise be called. That way we still print after the switch of screen buffers. I had thought that panic would prevent the `defer` from running, but I guess that is not the case? The above proposed methodology might work out better for us anyway and provide guarantees that the terminal resumes its normal modes.

sloum added the

bug

label 2019-12-04 16:38:31 +00:00

sloum added this to the 2.1.0 milestone 2019-12-06 03:23:56 +00:00

sloum self-assigned this 2019-12-06 03:25:17 +00:00

sloum referenced this issue

2019-12-06 06:06:03 +00:00

Display errors on browser failure #115

sloum commented

2019-12-07 05:42:06 +00:00

Closed by #115

sloum closed this issue