I3status-rust: Errors in blocks shouldn't make the bar unusable

[lovesegfault]

I have a laptop with a pretty nasty battery, sometimes it shows up, sometimes it doesn't, and it's a mess. In i3status, or i3pystatus, whenever my battery went rogue the 'block' on the statusbar would show a helpful "no battery". On i3status-rust, however, I get a huge red message covering the entire bar telling me my battery isn't there.

Moreover, if for example my weather API key isn't working (activation delay), I get another huge red message telling me it's invalid that covers the entire bar.

I think warnings and errors should either be pop-ups (i3-nag style), or be contained within their respective block, instead of covering the entire bar, which makes it unusable.

[atheriel]

I generally agree, although I think it's correct to error out in some cases. I'm working on a few patches to fix battery and network-related errors at the moment, which would seem to cover most of the annoying crashes due to temporarily failing sysfs reads or shell commands.

[lovesegfault]

Well, sure, I don't think erroring is a bad thing. I agree that it should error out in some cases (e.g. invalid API key for weather block), what I'm saying is how it should error. Instead of the whole bar becoming an error message, maybe just the particular block (and if the message is too big you could use the scrolling thing implemented in the music/media player block).
This way if for some reason the weather API is down, or my WiFi card is going nuts, or some other error, I can see that it is happening, but it also doesn't impair the rest of the (unrelated) functionality of the status bar.

[lovesegfault]

Just to provide an example of this happening. Every time I boot my computer it takes a few seconds for the Wi-Fi to connect proper, and because of that upon boot the statusbar is like this:

At which point I have to reload i3 for it to go back to normal. All I was trying to argue for in my previous comments was that errors like this should be shown in the block where they come from, like in i3status :)

[atheriel]

The key problem with this for the current implementation is that errors are propagated up to the bar level. The infrastructure for differentiating between fatal and non-fatal errors simply does not exist, and until it does I don't think there is a good way of addressing these problems. As a stopgap measure, I do think that we can (and will, when some time for this project materializes) silently fail on some of the obvious network/battery issues, but that is not a long-term solution.

[greshake]

@bemeurer In your case it is clearly the responsibility of the net block to catch this and just display 'None' or whatever. In general, if the blocks raise errors to the next higher level they shall be fatal. In cases like these the block is just missing the functionality, and it is good that the bar fatals so you guys will ping us and say 'Hey, the bar crashed when I pulled my internet connection- thats not right' and we can think of how to handle this case properly.

[greshake]

I looked into it and it's clearly a bug. The net block should just be hidden. Oh, and I've noticed the same thing for the weather block, and it is also a bug I noticed early on but just didnt have time fixing yet. These are however all cases we should implement handling for, and keeping errors fatal helps us to pressure the community not to ignore or endure these issues but instead to implement a fix or open an issue (sounds evil, but it makes for better software in the end for all). This strategy is certainly not acceptable in any setting, but here the worst that happens on a crash is the user having to press i3-reload or (temporarily) remove the bad block.

[atheriel]

I think this issue is a bit stale now; it's clearly the consensus that some classes of errors should not crash the bar. Outstanding issues with specific blocks should get their own issues, if they don't have them already.