Backend
Personal Expense Tracker V2 — Edit, Validation & Error Handling
Dhanush K DEV Community
3 views
I’ve completed V2 of my Personal Expense Tracker 🚀
This project started as a way to practice Python OOP, SQL, and SQLite by building something practical instead of only studying theory.
V1 focused on getting the core CRUD operations working.
With V2, I focused on making the application more reliable and user-friendly.
🆕 What I Added in V2
✏️ Edit Expenses
Users can now modify an existing expense.
The edit flow allows changing:
Amount
Category
Description
Date
Cancel the operation
This also gave me more practical experience working with SQL UPDATE statements and designing application flow around user choices.
🛡️ Input Validation
I also added validation for user input.
The application now handles things such as:
Invalid menu choices
Invalid amount input
Negative or zero amounts
Invalid category selection
Empty descriptions
Invalid dates
Impossible dates such as 2026-02-30
For example, instead of allowing invalid input to crash the program, the application asks the user to provide a valid value.
⚠️ Error Handling
While implementing validation, I also started thinking more carefully about where errors can happen and how the application should respond.
One important lesson was that input validation is not just about preventing crashes.
It is about defining what the application considers valid input and controlling the flow when the user provides something unexpected.
🧠 What I Learned
V2 taught me more than just how to add an edit feature.
I learned about:
Designing validation rules before implementing them
Using try/except for user input
Separating application flow from business logic
Handling different types of invalid input
Thinking about edge cases
Designing better CLI user interaction
Keeping the project scope under control
One thing I learned during this version is that not every possible improvement needs to be implemented immediately.
There are still things I could add, such as more advanced database error handling and additional checks, but I decided to stop V2 at the scope I originally defined.
That is also part of learning software development: knowing when a version is complete.
🏗️ Current Architecture
The project currently follows a simple separation of responsibilities:
main.py
↓
ExpenseManager
↓
Database / storage.py
↓
SQLite
main.py handles the CLI/application flow, ExpenseManager handles the application logic, and storage.py handles database operations.
📌 V2 Status
V2 is now complete.
The project currently supports:
✅ Add expenses
✅ View expenses
✅ Edit expenses
✅ Delete expenses
✅ Category selection
✅ Input validation
✅ Date validation
✅ Basic error handling
The main goal of this version was not to build a huge application.
It was to take the working V1 and make it more reliable while strengthening my understanding of Python, OOP, SQL, SQLite, and application design.
🔗 Project
📌 GitHub Repository: Personal Expense Tracker
I’ll continue improving the project in future versions when there is something meaningful to learn or add.
Thanks for reading! 🚀
Read original: https://dev.to/xdk0d3r/personal-expense-tracker-v2-edit-validation-error-handling-2935
← Previous
Vibe Coding Isn't the Problem. Calling It Engineering Is
Next →
NocoBase updates by primary key, not by your filter
Related
The fifteen ways a Google Play subscription breaks quietly
Backend
1
DEV Community
Java Concurrency LLD: Build a Custom BlockingQueue From Scratch
Backend
4
DEV Community
Mainframe Modernisation: Rewrite, Refactor or Replatform
Backend
5
Dev.to (EN Zone)
Engineering Build Notes #3: When 200Gi Was More Storage Than the Nodes Needed
Backend
6
DEV Community
Comments0
No comments yet — be the first