Move Throw into PscxCmdlet?

Topics: Developer Forum
Dec 24, 2006 at 8:00 PM
It might be nice to have this class as a static nested class in PscxCmdlet e.g. assume code executing in a PscxCmdlet derived class):


I can also see creating some generic delegates that execute code with a single instance of error handling code around it. That is I have a lot of code that handles file ops and the error handling code is largely duplicated. The problem being that if I figured out I need to catch another exception, I might not fix it in all places. Thoughts?
Dec 24, 2006 at 8:53 PM
Hmmm, not a bad idea. I guess we should also integrate it with PscxErrorRecord somehow...
Dec 24, 2006 at 11:18 PM
on the other hand, I am using it quite extensively in the PE header classes, which do not derive from PscxCmdlet, so it should probably stay a static class
Dec 25, 2006 at 7:05 AM
So perhaps not worth moving but could you change the name of the class? It strikes me as a bit odd to have a class named the same as a keyword (even though it is different casing).
Dec 26, 2006 at 1:40 AM
well it is an extension of the throw keyword, in a way. we could call it PscxException, but do you really think
is less confusing than
i would say it's only more verbose. and maybe more confusing, since the methods arent really throwing an PscxException. maybe calling it PscxArgumentException, but that is even more verbose.

i reflected a bit over the powershell code, they have methods like PSTrace.NewArgumentException(), which, in fact, return an PSArgumentException, which is derived from the System.ArgumentException.
There is no point in doing it this way for us, since we arent implementing a tracing mechanism, but we are trying to centralize (not only) argument validation, and we need the method to really throw the exception.

so i would stick with the Throw name.

but i'd like to move the PscxErrorRecord code in the PscxCmdlet. i was thinking about something like the following example:

class PscxCmdlet : PSCmdlet, IPscxCmdletOutput, IPscxCmdletErrorOutput
    protected IPscxCmdletOutput Ouput
        get { return this; }
    protected IPscxCmdletErrorOutput OutputError
        get { return this; }
    IPscxCmdletOutput.WriteVerbose(string msg)
        WriteVerbose(CmdletName + ": " + msg);
    IPscxCmdletErrorOutput.WriteFileError(Exception exc, string path)
        // the code from  PscxError.FileError

I am sure we would find some better names and organization of the methods and interfaces, but you get the idea...
Dec 26, 2006 at 7:28 AM
Following .NET guidelines, you should name a class using a "noun" and not a "verb" like Throw. How about:


where "this." is optional but reflects that these utility methods are available from PscxCmdlet. If you don't like Error pick some other "noun" please.
Dec 26, 2006 at 11:31 AM
ok, sounds good. we would use this.Error.ThrowXXX() to throw terminating errors and this.Error.WriteYYY() to write non-terminating errors. these methods would use static methods like PscxException.NewArgumentException() to create the exceptions with correct strings from resources and methods like PscxErrorRecord.FileError() to create the error records.

and I'd probably keep the Throw class, just for convenience sake. but we would use it only outside of the commands. maybe we could find these places and pass them the IErrorWriter reference instead, such they would directly write/throw using the command... on the other hand, i dont want to add an IErrorWriter parameter to each noncmdlet method...
Dec 27, 2006 at 4:41 AM
Cool sounds like a plan to me.
Dec 27, 2006 at 4:46 AM
This discussion has been copied to Work Item 6806. You may wish to continue further discussion there.