— Strengthening Error Handling: Designing How Systems Fail
[Class Report] System Development (2nd Year), Week 38
— Strengthening Error Handling: Designing How Systems Fail
During Week 38, we used the many bugs and exceptions discovered in last week’s integration testing as teaching material to systematically study error handling — including exception design, input validation, and user-facing message design.
Now that the app “works,” the instructor emphasized that we must design how it fails.
■ Instructor’s Introduction: “Apps that ignore errors cannot be trusted”
Instructor Tanaka:
“Working correctly only when things go well isn’t enough.
A professional system is one that is designed to behave correctly even when things go wrong.”
The instructor began by revisiting representative failures from last week’s integration tests:
- Database update failures → inconsistent state, incorrect inventory counts
- Raw exception messages shown directly in the UI (e.g., a raw ValueError)
- Uncaught exceptions causing the entire app to crash
- Insufficient error logs preventing root-cause investigation
These became our “textbook examples” for this week’s lesson on how to improve error handling.
■ Today’s Three Core Themes
- Input validation (UI layer)
- Exception design (Service layer)
- Recording and reporting failures (Logging & DAO layer)
■ Practical Exercise ①: Perform Input Validation in the UI
Many bugs originate from “unexpected input.”
Therefore, we reinforced the principle of defensive checks at the UI layer.
Example: When a numeric ID is required
raw = input("Book ID: ")
if not raw.isdigit():
print("Input Error: Please enter a numeric ID.")
return
book_id = int(raw)
Student A: “Just adding a numeric check reduced our errors by half!”
Validation Principles (from the instructor)
- Reject invalid input as early as possible at the UI
- But business-logic checks belong in the Service layer
- Error messages should be written in words the user will understand
■ Practical Exercise ②: Exception Design in the Service Layer (Domain vs. System Exceptions)
The Service layer handles business logic.
By classifying errors, code readability and maintainability greatly improve.
Example: Custom domain exception classes
class BookNotFoundError(Exception):
pass
class BookNotAvailableError(Exception):
pass
Usage in the Service layer
book = self.books_dao.get(book_id)
if not book:
raise BookNotFoundError()
if not book.is_available:
raise BookNotAvailableError()
The UI layer then responds with appropriate user messages depending on the exception.
Student B: “Naming the exceptions makes the meaning instantly clear!”
■ Practical Exercise ③: Failure Handling & Transaction Management in the DAO Layer
We implemented the following safeguards in the DAO layer:
- Always rollback transactions on database failures
- Log SQL errors internally (never show DB details in the UI)
- Transaction boundaries are controlled by the Service layer
Example: Exception handling inside the DAO (learning version)
try:
cur.execute("UPDATE books SET is_available=%s WHERE id=%s", (flag, book_id))
self.conn.commit()
except Exception as e:
self.conn.rollback()
logger.error(f"DB Error: {e}")
raise
Student C: “This fixed the ‘inventory mismatch’ bug caused by a missing rollback!”
■ Practical Exercise ④: Designing User-Friendly Error Messages
Displaying raw exceptions in the UI is a strict NO.
We practiced rewriting them into clear and friendly messages.
Before (bad example)
ValueError: invalid literal for int() with base 10
After (improved)
Input Error: Please enter a numeric Book ID.
Learning Points
- State exactly what was wrong
- Avoid phrasing that blames the user
- Provide guidance for correcting the input when possible
■ Practical Exercise ⑤: Distinguish Between Logs (for developers) and Errors (for users)
The instructor wrote this in big letters on the board:
**Logs are for developers
Error messages are for users**
The recommended pattern:
- Service or DAO writes detailed logs (internal use)
- UI displays a simple, polite message (external use)
Student D: “It’s so much easier to investigate problems when logs include the failing ID!”
■ Mini Exercise: List 10 Error Patterns
Each group listed errors under categories and discussed which layer should handle each:
- Input errors
- Authorization errors
- Business logic errors
- DAO integrity errors
- External API failures
- Transaction failures
- Unexpected exceptions (and possible fallback behavior)
Student E: “Once you categorize errors, the right handling location becomes obvious!”
■ Instructor’s Closing Message
“Error handling is a safety mechanism.
It’s the last line of defense that protects users and their data.
A system that ‘doesn’t break even when something goes wrong’
has far more value than one that works only under ideal conditions.
What you learned today will be essential for larger projects
and collaborative development.”
■ Homework (for next week’s implementation refinement)
- Create a complete error list for major use cases (group assignment)
- Produce a set of 10 improved user-oriented error messages
- Submit a mini integration test report covering the updated error-handling logic
■ Next Week Preview: Use Case Completion & Mini Presentations
Next week, you will demonstrate your fully completed use cases,
including the strengthened error-handling layer.
This will be the moment to showcase how stable your application has become.
In Week 38, students confronted errors head-on and took a major step toward building robust, user-safe applications.
They are beginning to see not only the developer’s perspective,
but also how to design for user confidence and safety.