Move Throw into PscxCmdlet?

Topics: Developer Forum
Coordinator
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):

this.Throw.IfIsNull

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?
Developer
Dec 24, 2006 at 8:53 PM
Hmmm, not a bad idea. I guess we should also integrate it with PscxErrorRecord somehow...
Developer
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
Coordinator
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).
Developer
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
PscxException.ThrowIfNullOrEmpty(arg);
is less confusing than
Throw.IfNullOrEmpty(arg);
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...
Coordinator
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:

this.Error.ThrowIfNotNull()

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.
Developer
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...
Coordinator
Dec 27, 2006 at 4:41 AM
Cool sounds like a plan to me.
Developer
Dec 27, 2006 at 4:46 AM
This discussion has been copied to Work Item 6806. You may wish to continue further discussion there.