|
Foothill wrote: Let me see if I can give a better example. Let's go with an web environment that supports both internal and external user logon.
I'm not sure I get what your function is doing. If the user has no access what happens to the principal (null, default/anonymous implementation)? Can the method return true and still set principal to null or return false and set the principal anyway? What if you decide for an anonymous principal (or whatever) instead, will it always return true? I'd have to read the documentation and trust it's correct (and I never trust documentation).
I'd expect (and prefer) something like the following, although I'm not sure how this would work out in actual code:
public static UserPrincipal GetPrincipal(string userName)
{
if (UserIsAuthorized(userName))
{
return new UserPrincipal();
}
else
{
return null;
}
}That code makes it pretty explicit that there is or isn't a UserPrincipal for a userName. The function now does one thing (retrieve the principal if it exists) and the function name makes it clear. There is also one less variable to worry about (which eliminates the questions I raised earlier).
Foothill wrote: The deeper I delve into C# and .Net, the more contradictions I find.
Many people worked on it and all had their own ideas and experiences. That .NET does it like this doesn't mean it's good or makes sense. Or maybe it does, but we don't know why 
I'd prefer the byte[] rndArr = rand.GetBytes(n); approach, but you might have guessed that
|
|
|
|
|
Ah, so even though I can find Microsoft code that does it, doesn't mean that it's encouraged or the best way to go about things. One takeaway that I am getting is that you should always write your code so simple that it lends to documenting itself even when you are writing companion documentation. I guess the out and ref keywords really are throwbacks to the old WIN32 API design style.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: Ah, so even though I can find Microsoft code that does it, doesn't mean that it's encouraged or the best way to go about things
Even though Microsoft preaches best practice they don't always practice it themselves 
Foothill wrote: One takeaway that I am getting is that you should always write your code so simple that it lends to documenting itself even when you are writing companion documentation
That's an awesome takeaway! 
|
|
|
|
|
Sander Rossel wrote: That's an awesome takeaway!
Just one of many, OG is giving me some great info on intricacies of exception handling below. There seems to be a leaning that out is only useful with TryParse style methods where you know exactly how a function could fail and you are given a choice how to handle it without having to surround the function with try...catch blocks.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: byte[] rndAry = rand.GetBytes(n);
Easy enough to implement with Extension Methods.
I might as well put some in my utility library. They likely will be useful.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Foothill wrote: With TryParse, it almost seems like it was designed to swallow certain exceptions and return false if they occur.
Yes it does seem that way, but that's not how TryParse works and it's important to understand that. As I mentioned above, exceptions are incredibly expensive and you should not be raising them lightly. The "Try" in TryParse doesn't mean there is an internal try\catch around the parse, it is there to indicate that it will try to do the work, but the work might fail. With Parse on its on there is no "might fail", with Parse we are saying that this operation is going to work because we know the text is of the correct format.
If you disassemble the code behind int.TryParse you will see that it verifies programmatically that the text can be converted to an int and if it detects otherwise it returns false - no exceptions or thrown or swallowed. int.TryParse is an incredibly frequently used function and if it generated exceptions internally then the resulting code would have incredibly poor performance.
|
|
|
|
|
Ah, that makes sense. TryParse is a very simple interface to what seems to be a complicated mechanism under the hood. Thanks for explaining it in greater detail.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Sander Rossel wrote: I really hope professional programmers grasp the concept
Been to QA recently? 
|
|
|
|
|
Since when do programmers visit QA? 
|
|
|
|
|
Well there are at least some who do! Guys like Richard who supply the responses. Most of them qualify
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I visit QA and try to find questions that I can answer but, for the most part, the senior programmers that haunt these halls give way better answers than I ever could.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Alright, I guess the (sado-)masochistic programmers among us visit QA 
|
|
|
|
|
The examples you've posted in reality would probably run asynchronous; in which case, any return values would be via call-backs and classes descended from EventArgs.
It's very hard justifying the use of "out" in an event-driven environment.
In any case, as soon as you need 2 "outs", it starts getting ugly / uglier.
|
|
|
|
|
I do use the out keyword, quite similar to your way of using it.
When looking for an item in a list with some condition, it is normally not an exceptional case when no item meets the condition (hence throwing an Exception is not appropriate). With a bool TryGetItemByCondition(object condition, out SomeType item), there is no more need to check item for null, thus simplifying the code.
|
|
|
|
|
Thanks for the input. I see that it might be good practice that when I also use out, I should clearly label the functions TrySomething(params, out result) to bring them more in line with established syntax.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
I occasionally use the out or ref keyword, but not often at all. Personally, if I need to return more than just some result I create a class. eg. In my DAL component I have a method that executes a given query and returns a Result class instance (Result is a class I wrote, nothing .Net native)
The result class in my case contains:
* The Dataset with the returned results (if any)
* A status enum
* An exception (can be null if everything goes well)
* The executed SQL
That way I have one line of code that executes the statement and one of code that will check wether that went OK or not. Notice that I have for more flexibility in my return object and if I ever need to change it (eg add a property to the Result class) I have a lesser change of high impact on the rest of the code.
in short. out and ref can be useful in some cases, but I would not use it as a rule of thumb.
That's my opinion anyway. 
|
|
|
|
|
I've also created a similar class class ,FunctionResult<t>, that used generics to populate the result with an accompanying status enum and an optional exception field. I understand the point that Sander eluded to previously that a Result class add an extra layer of complexity that might cause confusion to other developers if they are not familiar with it or if it is not a standard code practice in your organization.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
