There is no single answer, as this depends entirely on the project. We need to think about two things here. What is your eventual target? How do you expect to get there?
Are you writing Mars Orbiter control software? Then you better make damn sure you are writing the most robust code possible, You better be check every exception is handled in a sane matter.
Are you writing a program that only you will run, and you'll only run manually every once in a while? Then don't bother with exceptions. Don't bother with heavy architecture. Get it working to the point where it works for you.
How do you expect to get there?
Are you doing heavy waterfall development, where you spend lots of time figuring out what is needed, and then you will go off for months, developing? If so, then you want to hit that target quality mentioned above fairly early. Get all your error checking infrastructure planned out at the start.
Are you doing heavy agile development, where you are putting something together for a week or two, which will then be shown to stakeholders, who may ask for radical revisions, and where you expect to be able to iterate over many 1-2 wee sprints until you hit the target? Then you may be better off getting something working, but fragile together fast, and only adding belts-and-suspenders as the product requirements solidify.
If you are in control over the waterfall or agile decision (which is actually a continuum not a binary choice) then make that decision based on expected change. If you are sure you know exactly what the end result will look like, then waterfall is your best choice. If you only have a vague notion of what you need to end up with, agile is your best choice. (Agile is more popular these days not because it is inherently better but because the second situation is far more common.)
Now find your own answer
For most, the answer will lie somewhere in the middle. Answer both those questions about your project, and it should lead you in a basic direction.
I can say that for myself, if I often write one-off scripts that are abysmally designed and have no error checking whatever. I also handle production code, where error handling and architecture get large amounts of attention. It all depends on what you are doing.
One final caveat: If you decide you are doing one-off scripts that can be done quick-and-dirty, make sure. Unfortunately, it often happens that quick-and-dirty scripts that do something interesting get leveraged into broad usage when others notice them. Make sure that when this happens, time is given for hardening.