[Bug] Dead-code exception handlers in 3 route endpoints JSON 500 responses from PR #90 never execute

[parthdagia05]

Summary

Three route handlers have a pattern where a bare raise IOError above an except OSError block makes the structured JSON error response unreachable. Clients receive raw 500 stack traces instead of the clean JSON error that PR #90 added.

In Python 3.3+, IOError is an alias for OSError. So this pattern:

except(IOError):
    raise IOError
except OSError:
    return jsonify({'message': 'A filesystem error occurred.', 'status_code': 'error'}), 500

behaves as follows:

1. Any filesystem error raises OSError
2. The first clause catches it (because IOError == OSError)
3. raise IOError raises a new bare exception, losing the original traceback
4. A raised exception inside an except clause propagates out it does NOT fall through to the second except
5. Flask returns a raw 500 with a stack trace

The second except OSError is dead code. It never runs.

Affected routes:

• API/Routes/Case/CaseRoute.py:106-109 /copyCase
• API/Routes/Upload/UploadRoute.py:402-405 template deletion
• API/Routes/Upload/UploadRoute.py:652-655 batch import

Context: PR #90 added the except OSError: return jsonify(...) handlers specifically to stop leaking stack traces. The commit messages ("preserve existing IOError behavior") suggest the IOError re-raise was left intentionally but that decision makes the new OSError handler unreachable, which contradicts PR #90's stated goal. Clarifying whether this was an oversight or intentional before opening a fix PR.

What did you expect? (optional)

No response

How can we reproduce it?

Trigger a filesystem error in /copyCase e.g., make the data storage directory read-only, then POST to /copyCase with a valid session.

Expected: 500 with JSON {"message": "A filesystem error occurred.", "status_code": "error"}
Actual: 500 with raw HTML stack trace (PermissionError + full traceback)

Static check:

grep -A 2 'except(IOError):$' API/Routes/

Environment (optional)

Branch: main @ 5f8f89a
Python 3.10+ (IOError/OSError alias applies since Python 3.3)

Logs or screenshots (optional)

No response

Related issue, PR, or discussion (optional)

• Issue [Bug] OSError in route handlers is re-raised bare, leaking stack traces to clients #89 (original stack-trace leak report - closed)
• PR fix: replace bare raise OSError with structured JSON 500 responses #90 (added the except OSError JSON handlers that are now unreachable - merged)
• Commits d38c2dd and b541ecb explicitly "preserve existing IOError behavior" - this issue requests clarification on whether that decision was intentional given the dead-code consequence.

Proposed track

None

[parthdagia05]

@SeaCelo quick question on this: was keeping the IOError re-raise above the OSError handler intentional in PR #90, or an oversight?