When I'm writing a new program, I typically start by putting together the very basic user interface (command line handling, etc) and a very simplified version of the logic. I then progressively refine the code, adding functionality and handling edge cases as I improve things.
I've used this approach a lot in languages like Python, and it generally works well for me - I can ignore the details until I have the basic structure in place.
To do this in rust, though, I feel like I'd be doing an awful lot of unwrapping of results, letting the code panic if there are problems. Which is fine (it's the equivalent of having an unhandled exception in Python) and I'd just go back later and add error handling. Having explicit error types makes this much nicer, because it's easy to see where I've skipped over error handling.
But when I do come to add error handling later, the need to change return types feels like it makes the job a lot harder - the ripple effects of deciding I want to log a custom error message and then terminate the program cleanly seem like they are much bigger than (say) in Python defining a custom exception, raising it, and then catching it in my main routine.
How do people do this sort of thing in Rust? Accept the need for big "add error handling" exercises once you've outgrown panics? Include a very basic error handling framework in their initial code? Design error handling up front as a key program structure decision? Leave panics in and use a custom panic handler to at least make them look a bit nicer?
I feel a little bit like I'm reinventing the wheel here, and there "must" be some sort of best practice in this area. Or am I being excessively optimistic? Or is there a way of "gradually" enhancing error handling - moving from a panic to a very general error mechanism, to something more refined as needed - that I'm missing?