On 9 June 2016 at 13:29, Steven D'Aprano <steve@pearwood.info> wrote:
On Thu, Jun 09, 2016 at 12:54:31PM -0400, Ben Leslie wrote:
I think an exception is much easier for a user to deal with from a practical point of view. Trying to work out why a process has hung is obviously possible, but not necessarily easy.
Having a process crash due to an exception is very easy to diagnose by comparison.
That only makes sense if the application is going to block for (say) five or ten minutes. If it's going to block for three seconds, you might not even notice. At least not on a server.
But what are you going to do when you catch that exception?
- Sleep for a few seconds, and try again? That's just blocking.
- Stop waiting on secure randomness, and use something low quality and insecure? That's how you get exploits.
- Crash?
What does a program do when on any exception? It really depends on the program and the circumstances in which it is running. But I would think that in most circumstances 'crash' is the answer. In the circumstances where this is most likely going to occur (server startup) you are almost certainly going to have some type of supervisory program restarting the failed process. It will almost certainly be logging the failure. Having logs filled with process restarts due to this error until there is finally entropy is better than it just hanging. At least that is what I'd prefer to diagnose. I think the real solution here would be outside of Python; starting a process that needs entropy when the system isn't ready yet is just as silly as running a 'mount' on a disk where the driver is still loading, or 'ifconfig' on a network interface where the network driver isn't yet loaded. But that isn't really a problem that can be solved in the context of Python. Cheers, Ben