Error handling about i3status-rust

[pitkley]

Okay, that is what I was trying to say: output the error as a single segment to i3bar, then stop doing anything. 👍

[greshake]

Hmm... Without a doubt I can agree that error handeling isn't very good right now.
First, a few observations:

1. Users almost never get to see the stdout of the program, therefore usually seeing any errors/panics as "status program exited with code X" or something like that from i3bar only.
2. Errors in the block implementations usually indicate terminal failure, and we should not take emerging errors lightly or continue running as usual.
3. Error handeling in the case of this program should be very light. There are basically no cases where we should recover from errors, because the application is stateless, easily restartable and all errors should be configuration errors or be cause by one specific block.

My ideas now focus on indicating critical failure to the user, and terminating gracefully. My plan:

1. Use the result type for any block update and initialization, and provide a type of Error that has two properties: 1. Shorthand error message to be displayed in the statusbar, 2. Debug-level explanation that gets printed to stderr
2. Handle top-level configuration errors the same way.
3. Leftover errors should only come from framework code, which definitely constitutes terminal failure. Unwind all panics and print something like "Shit hit the fan. Please open an issue at github.com/greshake/i3status-rust with the stderr output of i3status-rust" to the status bar, and print the stacktrace and panic info to stderr.

[pitkley]

1. Use the result type for any block update and initialization, and provide a type of Error that has two properties: 1. Shorthand error message to be displayed in the statusbar, 2. Debug-level explanation that gets printed to stderr

Were you thinking of creating a block to display the error with? Because as far as I can tell, there does not seem to be a way to print an error and exit without i3bar taking over with default output.

2. Handle top-level configuration errors the same way.

Again, do you think a block displaying the error would be the right thing to do? Or should we look into something i3-nagbar?

---

Overall I'm very much onboard with the points you made, and I am going to look into implementing this.

Regarding the implementation of the errors: from the quick overview I gave and maybe your experiences, do you have any points against or for error-chain? If not, I would go ahead with using error-chain rather than implementing the conversions manually.

[greshake]

I imagined displaying only the error message in red on the status bar. I don't see why we'd want to continue running when one of the blocks fails, even less when there has been an error in framework code.

I don't see why we'd need the additional dependency... We only need to catch panics from the framework and handle Results from blocks. We don't have any need for complex error handeling or long error chains. The maximum "depth" at which errors occur is on block level.

[pitkley]

Ah, okay, so when you said "Shorthand error message" you were talking about the one generated by i3bar when the status_command fails ("status program exited with code X")?

[greshake]

Yea, I meant somthing to replace that message with something more descript. However I don't think we can influence that, but I guess we can just output one last update containing one block with the error message only. Suffices to just use a TextWidget, no need to implement an error block. We need to continue running though to avoid the error message being replaced by the default "status program exited with.... ". But, no more updates are required to keep the text, so we can just sleep indefinitely.

[jheyens]

I was thinking about failing blocks as well. I am convinced that most errors are caused by block implementations, and this should not be a terminal error (Framework errors should always panic in my opinion).
What I was thinking about, is:

• Framework error -> panic
• Block error -> set block to state critical, set text to something like "{block} crashed, click to save log", "register" click event
  • on click -> set block to state info, save error message in /tmp/{tmpfile}, set text to something like "{block} error message saved to /tmp/{tmpfile}", "unregister" click event

I think this might encourage users to open an issue with better information, as they only need to attach the error log file created.

[pitkley]

@jheyens not a bad suggestion regarding block errors only "crashing" a single block.

I'm gonna lay the groundwork for error handling probably today or tomorrow, currently with the behaviour of replacing the whole bar by a single error message. But this should be relatively easy to replace once the grunt work is done.

[greshake]

I don't think going from whole bar error state to single block yields any advantage. A user will want to reconfigure anyway, and we would have much higher implementation costs. But I like the click to save idea. Also, panics should be handled and treated the same way, otherwise panics just appear as the default error message from i3bar to the user.

[greshake]

I fixed some issues with displaying internal errors that occur when parsing the config or finding an unknown block. I'm happy with the error handling now, do you guys see need for improvement? There are still some yet unimplemented suggestions by @jheyens . If you all are happy I'm closing this issue.

[rubdos]

I'm happy with the error handling now, do you guys see need for improvement?

I think I need an improvement. I have a daily panic (around the evening), and I don't know what it is yet. I'm currently running RUST_BACKTRACE=FULL i3status-rust in a terminal since somewhere yesterday, in order to find out what it is.

• Block error -> set block to state critical, set text to something like "{block} crashed, click to save log", "register" click event

  • on click -> set block to state info, save error message in /tmp/{tmpfile}, set text to something like "{block} error message saved to /tmp/{tmpfile}", "unregister" click event

This would actually help finding it :-)

[greshake]

Yea, I have the same issue. Investigating as well...