Personal Expense Tracker V2 - Edit, Validation & Error Handling

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! 🚀 Top comments (0)