All software design and coding concepts and patterns arise in response to some problem. The pattern or concept is a solution to that problem. Over time, some patterns become "well-known" as preferable solutions because they solve the problem in a way that fulfills certain requirements for consistency, familiarity, performance, maintainability, and so forth.

It follows that, if the problem that the software pattern is meant to solve doesn't exist in your particular software, then you don't need the pattern. Further, any discussions of what patterns your software might need must also include detailed discussions of your proposed software: what is it supposed to do? What problem does it solve? How many users will there be? Will the users be sharing data in some way? And so forth.

For exceptions, specifically, the problem that exceptions are supposed to solve is when something happens that the code can't do anything about. An example would be a File/Open operation where a file name is specified that doesn't exist on the storage medium. Exceptions give the code a way to say to the caller "Something happened, and I can't handle it, so I'm giving up." If you don't have any places in your code where conditions like that exist, then you don't need exceptions. Or, you can simply return an error code, and avoid the exception altogether.

As you gain experience, you will learn about software patterns and when their use is appropriate. You will also know how much up-front design you need; again, that totally depends on the application you are writing. Small utilities are written in a fundamentally different way from large, enterprise applications, in other words.

All software design and coding concepts and patterns arise in response to some problem. The pattern or concept is a solution to that problem. Over time, some patterns become "well-known" as preferable solutions because they solve the problem in a way that fulfills certain requirements for consistency, familiarity, performance, maintainability, and so forth.

It follows that, if the problem that the software pattern is meant to solve doesn't exist in your particular software, then you don't need the pattern. Further, any discussions of what patterns your software might need must also include detailed discussions of your proposed software: what is it supposed to do? What problem does it solve? How many users will there be? Will the users be sharing data in some way? And so forth.

The problem that exceptions are supposed to solve is when something happens that the code can't do anything about. An example would be a File/Open operation where a file name is specified that doesn't exist on the storage medium. Exceptions give the code a way to say to the caller "Something happened that prevents me from continuing, and there's nothing I can do about it, so I'm giving up." If you don't have any places in your code where conditions like that exist, then you don't need exceptions. Or, you can simply return an error code, and avoid the exception altogether.

As you gain experience, you will learn about software patterns and when their use is appropriate. You will also know how much up-front design you need; again, that totally depends on the application you are writing. Small utilities are written in a fundamentally different way from large, enterprise applications, in other words.