Here's some quick points I'd make for this question:
- Use the -Force parameter with Get-Member;
- Use the -InputObject parameter with Get-Member rather than piping the object into Get-Member;
- If you need to know the full type name of an object, use the .GetType().FullName method;
- Once you have the full class name, you'll typically be able to look that up on docs.microsoft.com to get a reference article on the class.
Point 1: Use the -Force parameter with Get-Member.
Using -Force shows some additional properties you otherwise don't see, and these properties can allow for further exploration and explanation of what members exist and from where they originate.
Let's take a basic DirectoryEntry object run through Get-Member (sans -Force) as an example to explore.
Great! So, we have a list of members - cool. But how does that explain this?
After all, that's not in the output from Get-Member above. So, let's run it again with -Force:
We see a couple of debutantes. I won't go into all of these - that can be your homework, but let's look at one of them: psbase. You'll notice you can't Tab-complete these guys as they're classed as "hidden" types - I'll put the Docs article on them below the picture.
And so now we can see where that AuthenticationType came from: the base .NET class.
Here's the article on those intrinsic types, but it's also worth calling out now (early) that this is why the .NET reference articles on docs.microsoft.com are helpful: they make all of this a bit easier to discover, read and refer to as you go - or that's my opinion as an old-time geezer that grew up before computers were a household item and we still read a lot.
Point 2: Use the -InputObject parameter with Get-Member rather than piping the object into Get-Member.
PowerShell makes heavy use of collections, and Get-Member accounts for this by reporting the details of the objects inside the collection rather than of the collection itself. Most of the time this is helpful but sometimes it's not - sometimes you actually want to look up the collection type.
Here's the same command piped (top) and passed as a parameter (bottom). Notice the different class types reported?
While it's clearly a subtle difference, it's these kinds of things that can trip you up on occasion - particularly when it comes to working on larger scripts with numerous functions, as well as classes, etc.
Point 3: If you need to know the full type name of an object, use the .GetType().FullName method.
This is just a handy tip. The philosophy behind it is much the same as point 2, so I won't repeat it here - it's just a short-form way of quickly finding out the class type details.
Point 4: Use the .NET documentation on docs.microsoft.com.
The first three points really serve this fourth point, which is to be able to accurately and confidently look up the .NET class documentation on docs.microsoft.com.
PowerShell often obscures class names, such as you can see in the following example with PowerShell's shorthand for a hashtable (first example) and then a sorted dictionary (second example.)
Without using some combination of the three tips above, it's not obvious which properties and methods you have at your disposal, and in some cases, whether they're even the same thing at all (as the above case demonstrates they are indeed not.)
Ultimately, this helps you discover more possibilities on the fly (as with Get-Member) or, when you really get into the business of writing high-performance scripts, knowing what .NET options you can pursue on docs.microsoft.com.
Putting this all together to speak to your question about "is there a standardised set of methods?", then the answer is mostly: not really.
What there is are some handy ways to find out the underlying class you're working with, from which you can then go look up the formal reference on docs.microsoft.com or make do with Get-Member.
Let's use your question about the $error object as an example.
The first example quickly uses .GetType().FullName to reveal that $error is nothing more than a basic arraylist, where the subsequent Get-Member - being sure to pass it directly and not via pipeline - shows more detail about the members.
But what about the array elements themselves?
This is where it you can see Get-Member shine.
The top section shows me checking the four most recent elements within the $error ArrayList, and you can see there's two separate classes featuring in the ArrayList - probably not something the uninitiated would have guessed, but perfectly fine from a .NET perspective as an ArrayList is not strongly-typed and can hold any class.
Passing the $error ArrayList to Get-Member is a much easier way to get that same identification happening, as it automates the array inspection and reports each distinct class type it encounters.
So, as they say, horses for courses - all these means of inspection can help directly or indirectly with helping you come to grips with what's available on a per class basis.
Hopefully that gives you a little bit of a dynamic approach to learning your way around PowerShell classes.
Cheers,
Lain