>>>>>But unless the called method needs to access existing values using 'ref' is a waste of bandwidth.
>>>>
>>>>Hadn't thought about that but with and empty varchar going in for an errormessage are we really talking about a lot of bandwidth?
>>>
>>>In that instance - No. But still unnecessary. But if, for example, the parameter is a large object which needs to be marshalled then it is more significant.
>>>I'd argue that, just from a best-practice POV, if the called method doesn't require the parameter to be passed in then 'out' is best.
>>
>>I see your point. With the out param, where does the return value show up in the debugger? I don't remember what it was I ran into that drew me to the by ref but it seems it had to something to do with debugging. The out param is not defined before the call to the function, is it? I really need to look at all that again as I realize now there is some stuff there I'm fuzzy on having not used that signature for a while.
>
>One oddity with the debugger that I noticed when the param IS assigned a value:

   private static void Main()
>    {
>        string x = "Hello";
>        Doit(out x);
>    }
>
>    static void Doit(out string s)
>    {
>        //Debugger shows 's' as Hello
>        //Watch window allows 's+" Mate"' etc
>        // But not in code
>    
>        s = "GoodBye";
>    }

Ok, it's coming back to me now. This and the guideline Craig cites is what scared me away from out params. I'm not 100% convinced the bandwidth argument is compelling in any use-case I've seen. If I found myself needing something that big back as a param from a function I think I might start to look carefully at my design. Do you have an example in mind?