Nice program! Now refactor it.
Refactoring is changing your code so that it makes adding future functionality EASIER and FASTER.
1. Take everything inside of each case statement and move it to its own function. That's 13-14 functions for you.
2. Look for sets of two of more functions that have similar behavior and vary slightly, then merge each set into a single function using parameters to achieve the varying behavior.
For example, don't the dog years and cat years calculations look similar? What varies between those two snippets? Can you think of how to make a single function with parameters that could calculate dog or cat years AND takes less code than your current implementation?
3. If you're really feeling hopped up and want to try something advanced with classes, now take a look at that switch. Any time you see a big switch you should think about encapsulating what varies
. What if you created a "command" object for each function and corresponding English description? (For instance, FibonacciCommand.invoke() writes the Fibonacci sequence to a file. FibonacciCommand.getDescription() returns "Fibonacci Sequence". FibonacciCommand, then, is one of several classes that implements or extends Command, which is either an abstract class or interface that enforces the implementation of invoke and getDescription, and gives your main program a common TYPE to deal with.)
Now you can create new instances of the command objects and store them in an array. Loop through the array to print out your menu. When you receive input, look up the object from the array based on the number entered, and invoke the command from said object. Adding more commands to your program is simply creating a new command class and adding an instance of it to the array.
This last kind of refactoring creates a lot of new classes, so it's work with little short term value to show for it. However, it pays off in the long run if you continue to develop this into a large application. The first two refactorings, however, make your code shorter, particularly your main function (which is huge), and makes everything easier to read. A good rule of thumb is if you can't see the entire function on screen at once, it needs to be broken up into smaller functions.
And of course, what was said previously about error checking is totally correct.
Error checking good.