Back in my (limited) java programming days, I remember this nice feature where if I tried to make a call that could throw an exception, java would require me to handle that exception or pass it off to something that could.
Anyways, I am writing a piece of powershell code that messes around with objects in Active Directory, so I want to be very, very careful. I’ve gotten occasional remote timeout errors, and that is leading me toward the more general question:
“How can I know ahead of time which of these cmdlets can throw exceptions indicating dangerous conditions, and what is the list of those possible exceptions?”
I am wondering if the list of exceptions, per cmdlet, is way too long to address all possibilities. I also don’t want to just write a generic exception handler, as powershell seems to do OK in the general sense of error handling.
What’s the best way to determine, per cmdlet, the list of all exceptions that can occur? Is this even possible / feasible?
Thanks!
Heh, I think you started out on the wrong foot there. The jury is very much out on whether Java’s checked exceptions are a nice idea.
That said, what you ask is very difficult to answer. In Java, it’s clear to the compiler through static analysis what methods throw (or at least what they declare they will throw) what exceptions; this is a closed system existing solely in the process space of the compiler. In the real world of distributed heterogeneous systems, there is no universal checked exception framework. PowerShell cmdlets exist in the domain of a .NET appdomain in a win32 process, but they talk to backing systems on foreign servers using obtuse protocols like Active Directory which are a world apart both in implementation and general conception. Exceptional conditions may “flow” from one domain to the next, but they get warped, wrapped and mushed in all directions before they bubble up to you, the poor user at the console. In short, the answer is no. The general purpose Cmdlets (get-item, get-childitem) do not know about the underlying provider system’s propensity to cause errors, and nor can they reliably know this.
However, if you have a dedicated module for Active Directory (like ActiveDirectory module from Microsoft, or Quest’s QAD module) then it’s possible they have listed the exceptions that their cmdlets will surface in the case of exceptional conditions in the backing system. This help would be found – most likely – in the module (or snapin) help files, or on a per-cmdlet basis. Try running the following command:
This will show the full invocation syntax along with any notes the developers have felt good enough to bless you with. Pay particular attention to the footer; it’s here you’ll usually find a more general help topic like “about_thesecmdlets” that you may view with:
get-help about_thesecmdletsHope this helps.