|
Sometimes, you need out because any other solution would be unwieldy. For example, look at TryParse and TryParseExact:
public static bool TryParse(string s, out int result) The difference between Convert.ToInt32 and Int32.TryParse is that the former throws an exception, the later returns an OK / Fail result - and needs the out parameter in order to return the value as well.
While you could use Convert instead, and wrap it with a try...catch block to get the same effect, using exceptions as part of normal processing is an anathema to me (and is rather ugly). And user input checking is (or should damn well be) part of normal processing.
You could create a Generic type which contains the value and a bool but that's ugly and annoying as well.
One out or ref for good reason is OK - if it starts to get more than that, then probably it needs a class or struct instead.
And I do find the "using out and ref requires an understanding of pointers" a bit specious as well: if you don't understand them, then I suspect that an out parameter is the least of your problems!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Thank you for the input. I think I am getting a better understanding of when to use
out<\out>. Would you say that a fair example is in functions that accept user inputs and can throw or rethrow several different exceptions of which only a couple represent an actual problem and the rest of them represent errors in the user's input that can be safely swallowed within the function?<br />
<div class="signature">if (Object.DividedByZero == true) { Universe.Implode(); }<br />
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016</div>
|
|
|
|
|
No, the fact that it's user input doesn't matter.
It's that you need to return two values (in this example a good/bad signal and a processed result) where there isn't the option of including a "bad" indication in the result.
For reference types, a "bad" result can be null and anything else is OK - but with value types that isn't possible, and returning a nullable value type is exactly the same (in practice) as returning a special type that contains both results. But with the added complication that it can't be used directly once it's returned!
And throwing exceptions is fine and dandy, but I don't like using them as a part of "normal" processing - they are exceptional events, and have a cost associated (The True Cost of .NET Exceptions — Solution | Rico Mariani's Performance Tidbits[^] describes the situation nicely). Plus the code becomes ugly and tends to get omitted by beginners, so instead of teaching them good practices, they just ask the same old question in QA!
Plus, as Pete said in the thread below mine, returning a bool and an out parameter means that you don't need to pollute the heap with "extra" info, and the bool value doesn't persist.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Ah, makes sense. The article was a good read but, since my knowledge of the exact operation of the CLR is incomplete, I have a question.
Is there a computational difference between these two code blocks?
try
{
}
catch (Exception)
{
return false;
}
try
{
}
catch
{
return false;
}
I am curious if there are certain methods of exception handling that don't unwind the call stack and don't create any additional overhead when the exception occurs. I can see this to be more appropriate in situations where I need the code to just reply, 'Sorry Dave, I'm afraid I can't do that' instead, as exceptions are appearing to be, calling the fire department. In this sense, when iterating through ten million rows in a database that requires you to convert strings to numbers and dates (which is understandably poor design), I would think it would be better to hit the exception and pass over it, possibly flagging it for later remediation, without creating a whole lot of exception overhead so that processing millions of rows could be done in seconds instead of minutes. Am I in the ballpark with this one?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
No difference - they both catch all exceptions. And so are both equally bad in most designs - you should only catch exceptions you can deal with: Why catch(Exception)/empty catch is bad | .NET Blog[^]
Try adds an overhead anyway (because it has to put a marker on the stack so the exception throw can "rewind" to it), so adding a try...catch inside a loop is going to extend the processing time for all operations inside the loop, not just the "failures".
And it depends on what exactly you can do about the exception! If it's a "data conversion error" in a row, what you should do about it depends on what exactly you are going to do with the data - there is no "hard and fast rule" that says you should ignore it and continue (logging it for a later fix), or abort the whole run. If you are processing bank transactions then ignoring something very odd is probably not a good idea - but if it's a student grade for an exercise you can probably ignore it (until the end of term, at least).
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
These are all very good points. The article is a good read, also. If I am putting this all together correctly, peppering your code with try...catch blocks may be acceptable during development to find syntax errors and bugs but the code that goes into to production should be written to handle what exceptions it can or die by fire if it runs into one that it cannot.
Another question, is there a mechanism in the runtime that could respond to an exception without using try...catch?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
The short answers are: "no", and "no"!
Production code should be the same as the dev version you are testing - you may well use some more try...catch blocks to get a better idea of why your code fails, but you shouldn't let your app "die in a fire" in production! That's ok for dev, but for prod you will really annoy your users if they type for an hour and then you crash and they lose it! (Think about any Corel product and you'll see what I mean).
It's a balancing act: putting in enough so that you can cope with problems, but not so much that they have an adverse effect on performance.
And there is no mechanism for handling exceptions other than: 1) try...catch, and 2) die in a fire.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I see that I got that point backwards. Sorry, I'm still assimilating a lot of information from the other answers to this question, some of which seem to boil down to personal preference.
I think that I am getting the point. The usage of out is to give the programmer more than one way to approach functions that can/will fail in predetermined ways and to provide the programmer with choices on how to handle them. If one prefers, they can handle an exception from Convert.ToInt32(object) or respond to a false return of Int32.TryParse(object, out int) . Additionally, this can or cannot be applicable given the code's context and task. Still, both methods seem equally fine to me.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Not just that, but yes.
The Exceptions part is just an example - there are load of other cases where you might want to use an out , but they are harder to explain in isolation.
For example, you might want to split out certain values from a collection and return the number of them:
private int GetForSomeReason(List<MyClass> mc, out List<MyClass> result, string somethingToLookFor)
{
... That way, you can chain them together:
int total = GetForSomeReason(myList, out listOfJoes, "joe") + GetForSomeReason(myList, out listOfMikes, "mike"); (I'm not suggesting that that's a good design, just a trivial example of a complicated scenario)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I can see that there are cases when out would make sense when it would save time later in program execution if the same information gathered in one function will be needed by another function in the event that the correct conditions are satisfied.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
As in everything else, it really depends what you are trying to solve. I have seen many contorted solutions to avoiding the use of out parameters and whether or not they make sense really depends on what the intent of the code was. Let's take the Try... routines. With later versions of the .NET framework, what could the API designers do? One option is to use a class structure that looks something like this:
public class Parse<T>
{
public bool HasValue;
public T Value;
} This could then be the target of something like this:
Parse<int> value = int.TryParse("12");
if (!value.HasValue) return;
DoSomething(value.Value); While this may seem to be a reasonable solution, on the surface, there are several issues with this design. The biggest problem I have with it is that you are allocating a larger object than you need to. Even if we were to change this to a struct, it's still an unreasonably large surface area for a simple value. Another problem is the cumbersome syntax of having to use value.Value to get the value - you could use implicit operators to work around this but that's adding extra burden again. Granted, the language could be extended with syntactic sugar to hide the underlying implementation (much like null operator hiding the underlying Nullable<T> implementations) but this is, again, overkill because Nullable types were added to support a real problem in the codebase.
So, what other options have I seen? Well, I have seen people returning a tuple with the first parameter being the success or not of the operation. I have seen people advocating the use of exceptions - thereby largely missing the point and I have seen delegates in various forms being required to set values. I have also seen APIs that require multiple calls, the first being a CanParse (or whatever command you need here), followed by a Parse - this being a particularly daft operation because you are effectively calling parse twice - the first one being required to see if you can parse the value, and then the second one being called to get the same value out that you would have got out with the previous operation.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: While this may seem to be a reasonable solution, on the surface, there are several issues with this design. The biggest problem I have with it is that you are allocating a larger object than you need to. Even if we were to change this to a struct, it's still an unreasonably large surface area for a simple value.
I'm having some trouble grasping the rationale here, mostly due to the "unreasonably" part. I'm hard-pressed to quantify an extra bit value as unreasonable, especially since it's bundled with a possibly null value and enables an almost English-language null-check mechanism.
After all, the Tuple solution will result in the same memory reservation with the same ubiquitous value access (though I find variable.Item2 less useful than variable.Value).
The exception solution potentially breaks the "don't use exceptions for flow control" rule, which is one of those rules that actually makes objective sense.
I suppose you could use an event driven parser instead, but that introduces even more code overhead.
Now that I think about it, that might be worth working up to add to my library, thanks for the idea!
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
It's worth noting that I'm not recommending the Tuple approach either. Basically, what I'm talking about is the fact that you are potentially allocating a class here (if you define this as a class) that will be created on the stack, rather than being on the heap for a reference type. And remember that the boolean return value is going to exist for longer than it needs to if you define your Parse class/struct as a member variable.
This space for rent
|
|
|
|
|
Absolutely understood on the Tuple part. What I saw was what you perceived to be a collection of "bad" ideas.
In terms of cost, though, I've just always seen the intrinsic resilience value of the wrapper class to considerably outweigh the cost of having an extra bit floating around for a GC cycle. Even in aggregate, it would take a massive dataset being processed through a poorly-devised pipeline (after all, how hard is "variable.HasValue ? yield variable.Value : continue"?) in order for that to even show as a blip on the radar.
I suppose I'm mostly curious about a different point of view, mainly how the cost-benefit analysis works
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
The key part was my first sentence that it all depends on the context. My point there was that there are times when it's simpler and more appropriate to just return an "out" value, rather than having to contort yourself for the sake of purism. I deliberately focused on the OP's sample because the Try.... don't really need to do much more than they do. Now, suppose we wanted to extend the example, what about if we were looking to answer the question of why did it fail? Then it becomes more appropriate to return a struct/class.
public class Parse<T>
{
bool HasValue { get; set; }
T Value { get; set; }
string AdditionalInformation { get; set; }
}
This space for rent
|
|
|
|
|
Thank you for the level of detail in your posts. If I may, I will attempt to extrapolate some meaning. What I am think I am understanding is that, as one is writing code, the coder should use a minimalist approach first, only writing what is necessary. When the problem cannot be solved or the task completed and still have the code make sense when it's done, then that is when some of the more advanced (I use that term loosely here as pointers are nothing new) features of the C# language that could simplify what might otherwise have a bit of a learning curve. Is this at all similar to what you are implying?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
You could always use nested classes to (somewhat) avoid the extra storage:
public abstract class Parse<T>
{
public abstract bool HasValue { get; }
public abstract T Value { get; }
public abstract string AdditionalInformation { get; }
private sealed class ParseSome : Parse<T>
{
public ParseSome(T value)
{
Value = value;
}
public override bool HasValue => true;
public override string AdditionalInformation => null;
public override T Value { get; }
}
private sealed class ParseNone : Parse<T>
{
public ParseNone(string additionalInformation)
{
AdditionalInformation = additionalInformation;
}
public override bool HasValue => false;
public override string AdditionalInformation { get; }
public override T Value
{
get { throw new InvalidOperationException(AdditionalInformation); }
}
}
public static Parse<T> Some(T value)
{
return new ParseSome(value);
}
public static Parse<T> None(string additionalInformation)
{
return new ParseNone(additionalInformation);
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Not a hard-and-fast rule, but I have often found that if I need an out or ref parameter, it indicates that my object model might be wrong.
Of course, it's not always easy, or possible, to get that entirely as you would like it, due to the interfaces that need to be used.
However, as perhaps a poor example (since you admit your example isn't the best), instead of:
public bool IsProductOnSale(guid productId, out Guid[] productResellerIds)
{
}
maybe you would consider having "Product" objects, instead of using a raw id. This could then contain all the information you need, and/or look it up as-and-when required:
e.g:
class Product
{
private Collection<Seller> resellers;
public Collection<Seller> Resellers
{
if (null == resellers)
{
}
return resellers;
}
public bool IsProductOnSale()
{
return (Resellers.Count > 0);
}
}
Then you could do
if (myProduct.IsProductOnSale) { foreach (Seller in myProduct.Resellers) { ... }
without obtaining the information from the database twice. Your calling code doesn't even need to know how (or when) the information is retrieved - you might decide to do it in the constructor.
Your constructor for Product would probably take a guid... etc, etc.
|
|
|
|
|
Thanks for the input. I have classes similar to your Product , which wrap up data from a database into an object to be used by other functions. With my example, the idea I was working with is that here is a function that connects to the database and retrieves data that can change any time (e.g. Product). I also have data that changes infrequently and can be kept in memory and is periodically refreshed (e.g. Reseller). Would it make sense to fetch a result set of variable data and use the out parameter to contain related persistent data that you already have? Or would it be better to break this into two or three other functions for each step?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
I have a simple winform (C#) with a text box and a button.
My requirement is that while the button is clicked the text box content should be added with "Some message". As long the button is in clicked status the message in text box should be kept on adding.
The moment I let go the button (remove my finger off the mouse), this adding message to text box should stop.
Is there a while clicked loop possible in a button click event ?
|
|
|
|
|
Timer, set to 10ms interval
Set the text box text based on whether the button is clicked currently
|
|
|
|
|
Do you want to keep the message posted when there is button pressed, as soon as you release the button it should stop posting right ?
The click event will not help you anymore here, cause click is the combination of 'keyPress' and 'keyUp' event
you need to handle both events, on 'keyPress' post the message in textbox and on 'keyUp' event stop posting
hope it helps
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Don't you mean MouseDown and MouseUp?
|
|
|
|
|
Oooops big typo.
Yes, I mean MouseUp and Down event with timer will accomplish his task
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Don't use a Timer. Use the methods on the Button MouseDown to start the update and MouseUp to stop the update.
You should probably do the updating on a separate Thread ... this CodeProject article can be adapted to do what you want - Simple Threading[^]
For example I have a button btnDemo - when I hold it "down" with my mouse a label lblDemo will get a number displayed. When I release the button then the label will get the text "stopped"...
Here is the code that handles the mouseclicks on the button
private void btnDemo_MouseDown(object sender, MouseEventArgs e)
{
demoThread = new Thread(ThreadProcSafe);
btnDemo.Text = "Stop Demo";
demoThread.Start();
}
private void btnDemo_MouseUp(object sender, MouseEventArgs e)
{
if (!stopDemo)
{
stopDemo = true;
if (!demoThread.Join(1000))
{
demoThread.Abort();
}
SetText("Stopped");
btnDemo.Text = "Start Demo";
}
} And here is the code that actually sets up the thread and SetText functons (with some very basic error handling). These are the bits you need to change to put your message in your TextBox
delegate void SetTextCallback(string text);
private Thread demoThread;
private volatile bool stopDemo;
private void ThreadProcSafe()
{
var x = 0;
while (!stopDemo)
{
SetText((x++).ToString());
Thread.Sleep(600);
}
}
private void SetText(string text)
{
try
{
if (lbl_right.Disposing) return;
if (lblDemo.InvokeRequired)
{
var d = new SetTextCallback(SetText);
BeginInvoke(d, text);
}
else
lblDemo.Text = text;
}
catch (Exception e)
{
MessageBox.Show(e.Message);
}
}
If you read the article it points out that sometimes the threads won't close properly when you attempt to close the application. Because we have the thread starting on a mouse down and ending on the mouse-up this is less likely but still worth adding this method into the form -
protected override void OnClosed(EventArgs e)
{
stopDemo = true;
if (!demoThread.Join(1000))
{
demoThread.Abort();
}
base.OnClosed(e);
}
|
|
|
|
|