Fix/449 dead code exception handlers

[parthdagia05]

Linked issue

• Closes [Bug] Dead-code exception handlers in 3 route endpoints JSON 500 responses from PR #90 never execute #449
• Related [Bug] OSError in route handlers is re-raised bare, leaking stack traces to clients #89, fix: replace bare raise OSError with structured JSON 500 responses #90

Existing related work reviewed

• Issues/PRs reviewed:
  • #89 - Original stack-trace leak report (closed)
  • #90 - Added except OSError JSON handlers that are now unreachable (merged)
  • Commits d38c2dd and b541ecb - "preserve existing IOError behavior" (root cause of the dead code)

Overlap assessment

• Classification: Follow-up fix to fix: replace bare raise OSError with structured JSON 500 responses #90
• Overlapping items: PR fix: replace bare raise OSError with structured JSON 500 responses #90 added the except OSError JSON handlers this PR makes reachable
• Why this is not duplicate/superseded: PR fix: replace bare raise OSError with structured JSON 500 responses #90 is merged but its JSON error handlers are unreachable dead code due to the except(IOError): raise IOError blocks left above them. This PR completes fix: replace bare raise OSError with structured JSON 500 responses #90's stated goal.

Why this PR should proceed

• PR fix: replace bare raise OSError with structured JSON 500 responses #90 intended to return structured JSON 500 responses for filesystem errors, but the except(IOError): raise IOError pattern left above the new handlers makes them unreachable. Clients currently receive raw HTML 500 stack traces, leaking internal details. This is a minimal 6-line deletion that fixes the bug without changing any other behavior.

Summary

• What changed: Removed except(IOError): raise IOError blocks from 3 route endpoints:
  • API/Routes/Case/CaseRoute.py - /copyCase (lines 106–107)
  • API/Routes/Upload/UploadRoute.py - uploadCaseUnchunked_old (lines 402–403)
  • API/Routes/Upload/UploadRoute.py - uploadXls (lines 652–653)
• Why: In Python 3.3+, IOError is an alias for OSError. The pattern except(IOError): raise IOError catches any filesystem error (since IOError == OSError), then re-raises it. A raised exception inside an except clause propagates out - it does not fall through to the next except. This made the except OSError: return jsonify(...) handlers added by PR fix: replace bare raise OSError with structured JSON 500 responses #90 completely unreachable.

Validation

• Tests added/updated (or not applicable) - No new tests needed; this is a 6-line deletion removing dead code. Existing behavior is unchanged except filesystem errors now return JSON instead of stack traces.
• Validation steps documented
  • Static check: grep -n "except(IOError):" API/Routes/Case/CaseRoute.py API/Routes/Upload/UploadRoute.py - confirms no raise IOError patterns remain
  • Runtime check: Make the data storage directory read-only, then POST /copyCase with a valid session → should return {"message": "A filesystem error occurred.", "status_code": "error"} with HTTP 500 instead of a raw stack trace
• Evidence attached (logs/screenshots/output as relevant)

Documentation

• Docs updated in this PR (or not applicable) - No documentation changes needed; this is a bug fix removing dead code.
• Any setup/workflow changes reflected in repo docs - N/A

Scope check

• No unrelated refactors
• Implemented from a feature branch (fix/449-dead-code-exception-handlers)
• Change is deliverable without upstream OSeMOSYS/MUIO dependency
• Base repo/branch is EAPD-DRB/MUIOGO:main (not upstream)

Exception rationale

[Cypher-CP0]

Hey, good find on the dead code!
Quick question on the approach, instead of removing the except(IOError): raise IOError blocks entirely, was there any consideration to replacing them with explicit except OSError handlers directly? Since IOError == OSError in Python 3.3+, would making that explicit improve readability for future contributors who might not be aware of the alias?
Just curious on the thought process, the deletion approach makes sense too since the handler below already covers it.

[parthdagia05]

@Cypher-CP0
I removed the except(IOError): raise IOError blocks because they were redundant and breaking control flow. Raising inside that block exits the try-except early, making the downstream except OSError handler unreachable.

Replacing it with except OSError would still risk duplicating or shadowing the existing handler, so removal was the cleanest minimal fix.