Closed vbanos closed 4 years ago
I tried to replicate this problem in my dev machine without success. I run warcprox, wrote a few records in a WARC and then deleted the WARC file manually. warcprox didn't have an issue. It created a new file and moved on.
If I read the code correctly, it sounds like handling this exception would mean files that were already closed (forcibly by an external process?) will now also be renamed to remove the .open
, instead of leaving the filename to signify that "something weird happened here."
Is that right? (It sounds like we have no easy way to confirm this in the test environment.)
I think this is a good change, but I'm wondering, why not just catch Exception
, rather than try to enumerate specific exception types?
Separately, we should try to figure out why this happens.
From my experience, the more specific we are with exception handling, the better we understand what is going on and we can fix it eventually. Specific exception types imply specific problem types.
The exception is logged either way, catching Exception
won't hide useful information
OK NP, changed it to catch Exception
.
Thanks!
We get a lot of the following error in production and warcprox becomes totally unresponsive when this happens.
Current code handles
IOError
. We also need to handleValueError
to address this.