"Solved" certainly shouldn't mean "avoided entirely". One way to write good software is to quickly recover from mistakes. So instead of staring at your code while you triple-check each corner case, you approach the problem from the other direction by testing each code path until you're confident that the code runs as it should for the inputs that matter. (Be sure to assert for all other inputs).

In that light, it is easy to see why it can be good to crash for invalid cases. Since you don't handle a bunch of failure cases, you end up writing less code. And since less time is spent in the debugger, more time is focused on the correct task: achieving architectural goals rather than solving structural problems.

After you acquire a deeper understanding of the architecture, it is best to redesign (throw away) your previous attempt. After the second and especially the third iteration you will have written a solid and elegant program in a relatively small amount of time. Programming is about trusting yourself to make decent decisions based on your current knowledge.

As with anything, there is only a finite amount of time to solve a problem. So if you don't have a lot of time then don't fret if your code isn't perfect (or reusable) as long as it works.