Depends on how "correct" you want to be with how you handle it. Ideally, you'd handle all of the errors, and only suppress the ones that involve a computer that can't be contacted, but still display any other errors that might be of interest to you. I don't have the exception type handy, but the code can look something like this:

Then there's the "sweep them all under the rug" approach... it's not really a good practice, but if you really don't care about the errors and just want to display the successful output, you can just add "-ErrorAction SilentlyContinue" to your call to Invoke-Command, and not bother to look at the errors later

You're on the right track, but your braces are in the wrong places. It helps to use a consistent style of indenting and line breaks when writing code, to make it easier to read. I've revised the code a bit. In particular, I moved the call to Format-Table out of the loop, and piped objects to it at the end. You might find that this produces cleaner output; give it a try:

Basically, yes. When you use ForEach-Object, the current object is stored in the automatic $_ variable inside the -Process script block. (Normally, as in my example, this is the only script block passed to ForEach-Object, and it's passed by position, not name.)

Because the $_ automatic variable is used by all sorts of things, sometimes you can run into problems with it being "hijacked" by some other code inside the block (such as inside a Catch block, where $_ refers to the error that was caught.) For that reason, I'm in the habit of assigning the contents of $_ to another variable as the first statement in any ForEach-Object block. This way, the object will be stored in the $computer variable, regardless of what may happen with $_ later. It's not always absolutely required, but it's a good habit to have; you'll avoid some irritating bugs this way.