Python 'continue' interfering with 'try/except' or 'with'?

Question

I have an old script doing its duty for years now, which suddenly failed, and I don't see how it can even get to the point where it fails, since I thought to have that case eliminated:

It should go through a list of files (content of a directory), and if the current file ends with .sum , it should check if there is a file with the same name minus the .sum ending (like file1.txt.sum and file1.txt ). If both files exist, it should make a checksum of file.txt` and compare it to the content of the checksum file.

Only if this check is successful, there will be further operations ending with both files getting deleted from the directory.

for file in filelist:
  checksum_downloaded_file, checksum_from_checksumfile = '0', '1'
  if file.endswith('.sum'):
    # read checksum from checksum file
    f_sum = open(SAVETO + file, 'rb')
    with f_sum:
      checksum_from_checksumfile = f_sum.readline().split(' ')[0].rstrip().lower()
    # checksum() the file
    try:
      f = open(SAVETO + file[:-4], 'rb')
    except:
      continue
    with f:
      checksum_downloaded_file = hashlib.sha256(f.read()).hexdigest()

    # compare delivered checksum with selfmade
    if checksum_downloaded_file == checksum_from_checksumfile:
      [...]
      sftp.remove(file)
      sftp.remove(file[:-4])

I thought the check if a file exitsts with the same name as the checksum file except the .sum ending would be done in a reliable way by the

    try:
      f = open(SAVETO + file[:-4], 'rb')
    except:
      continue

block. But today the script failed while trying to delete both files at the end of the script, because the file without .sum ending didn't exist. How can this happen? Doesn't continue do its job in that context?

EDIT: Since it seems there is nothing logically wrong with the code, the error might lay outside (although I don't know how it could). Therefore further informations: The actual source of the files is a directory reached via SFTP (pysftp used). The filelist is filled by filelist = sftp.listdir() , and all files are downloaded (to SAVETO ) before the problematic block starts. They should get removed on the SFTP server with sftp.remove(file[:-4]) afterwards and this is where the script fails throwing

Traceback (most recent call last):
  File "script.py", line 71, in <module>
    sftp.remove(file[:-4])
  File "/home/alba/.local/lib/python2.7/site-packages/pysftp/__init__.py", line 728, in remove
    self._sftp.remove(remotefile)
  File "/home/alba/.local/lib/python2.7/site-packages/paramiko/sftp_client.py", line 365, in remove
    self._request(CMD_REMOVE, path)
  File "/home/alba/.local/lib/python2.7/site-packages/paramiko/sftp_client.py", line 780, in _request
    return self._read_response(num)
  File "/home/alba/.local/lib/python2.7/site-packages/paramiko/sftp_client.py", line 832, in _read_response
    self._convert_status(msg)
  File "/home/alba/.local/lib/python2.7/site-packages/paramiko/sftp_client.py", line 861, in _convert_status
    raise IOError(errno.ENOENT, text)
IOError: [Errno 2] No such file or directory

EDIT2: Still can't let this go. I guess if the file got deleted on the server after the script downloaded it, the script would fail like this because of course the file wouldn't be there then anymore. But the script failed every time from then on. Doesn't make sense..

EDIT3: Solved in answer. Thank you for your time and patience.

Answer 1

My first approach to search for the bug in the code gave the title to this thread, and it turned out to be wrong.

The bug happens when the input directory gets fed with a checksum file, which already has been fed in the past, and back then correctly, ergo with a correspondent data file, but now without that correspondent data file: The (again) downloaded checksum file gets evaluated and the script looks for a correspondent data file, which is still present in the working directory from the past. It runs its operations and finally tries to remove the checksum and the data file from the input directory, which fails for the data file.

An unforeseen, unhandled case; out of the initial specifications, but still embarrassing. I learned from this to sort the list of debugging approaches more realistically.