Answer the question
In order to leave comments, you need to log in
What I/O errors should you fall on and which ones should you try to fix?
I am a novice Rust programmer, writing backends and feeling that in production you can’t just fall on all I / O errors, I ran into the issue of their correct handling.
It is clear what to do if the file does not exist, there are no rights, the place is over or the file is busy, but what about such Linux errors?
EIO (I/O error)
EINTR (Interrupted system call) //what could possibly interrupt the system call?
EL2NSYNC (Level 2 not synchronized)
EL3HLT (Level 3 halted)
EL3RST (Level 3 reset)
ENOANO (No anode)
What is the list of errors that generally makes sense to process if we are talking about working with local files and sockets? What errors should be used to kill the problematic thread, but continue working? Or maybe there are some mistakes in which it is worth panicking and not trying to save anything right away?
Answer the question
In order to leave comments, you need to log in
I/O exceptions are one of the most difficult decisions to make. This is due to the fact that the network is part of the outside world. The one you have no influence on. What could be the reason? There should be a decision table for every error class and every data source. For example, you know that every Thursday this rest service has a possible update schedule. Give out a tile with a message about the regulations on the UI and ask to repeat after a while. And another rest service just hangs on a weak channel. And you need to apply RetryLogic to it. Silently. There is simply no other way.
There are no general recommendations.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question