Toi add to what Rick has said, you should expect to get syntax errors every day, probably many times a day while you are coding - we all do regardless of how much experience we have! Sometimes, we misspell a variable, or a keyword; sometimes we forget to close a string or a code block. Sometimes the cat walks over your keyboard and types something really weird. Sometimes we just forget how many parameters a method call needs. Or in your case, type
void
randomly into our code!
We all make mistakes.
And because we all do it, we all have to fix syntax errors - and it's a lot quicker to learn how and fix them yourself than to wait for someone else to fix them for you! So invest a little time in learning how to read error messages, and how to interpret your code as written in the light of what the compiler is telling you is wrong - it really is trying to be helpful!
So read this:
How to Write Code to Solve a Problem, A Beginner's Guide Part 2: Syntax Errors[
^] - it should help you next time you get a compilation error!
And spending a little time learning to understand syntax error messages will save you a huge amount of time in future: you waited at least 1/4 hour for Chris to reply, then your email system probably added another 10 minutes or so, plus the time it took you to type up the question once you had found this site and created an account. Chances are that you could have saved a significant chunk of that time if you knew how to read them!
I'm not saying we don't want to help you fix them - sometimes I can't see my own errors because I read what I meant to write - but fixing syntax errors is part of the job, and if you can't do it for yourself people are going to look at you as a bit weird should you get a job in the industry!
Once you have got rid of the syntax errors, it's time to look for runtime errors - which means running your code and testing it. When your code does something you don't expect, it's time to find out why. Fortunately, you have a tool available to you which will help you find out what is going on: the debugger. How you use it depends on your compiler system, but a quick Google for the name of your IDE and "debugger" should give you the info you need.
Put a breakpoint on the first line in the function, and run your code through the debugger. Then look at your code, and at your data and work out what should happen manually. Then single step each line checking that what you expected to happen is exactly what did. When it isn't, that's when you have a problem, and you can back-track (or run it again and look more closely) to find out why.
Sorry, but we can't do that for you - time for you to learn a new (and very, very useful) skill: debugging!