β Passing a potential NULL value, is it allowed?
Would this be valid even if the
input
argument for InputHandler.zeroinputargument(input);
and InputHandler.twoinputarguments(input);
might be NULL?17 Replies
As in, what if my method
run
s argument was NULL. Would everything still work?the code as-is? sure, it doesn't automatically crash just because you passed null
it will crash if you try to access members of a null variable, like accessing elements of the array or calling a method on the array
It rather depends on what
zeroinputargument
does with its input
parameterAhhh
zeroinputargument
wont use input parameter
might as well remove it :p
:catlaugh:
Not sure what i was thinking there, my bad
Quick question
If this program was started where no arguemnts were specified
would the string[] be NULL ?No
It would be an empty array
Aaah that makes sense
So if I wanted to check for that Iβd aim for something like
if (args.Length == 0)
Actually if you pass no arguments then the array will have one item
The item is the file path to the program
Interesting
Iβll remake it and see
You are a legend @a coding witch. It indeed comes out to 0!
Great
There is another way to get the arguments
By any chance, do you also know if i were to do
string text = Console.Readline();
And the user inputs 2 3 +
would the 2 and 3 become also strings? Are there types that identify each one as is? For example 2 is int, 3 is int, space bar is string and + is string?ReadLine only gives you one string, and that string is everything the user typed before hitting enter
you'll have to do some string processing/parsing to turn that one string into individual numbers/symbols/etc
$tryparse will be relevant
When you don't know if a string is actually a number when handling user input, use
int.TryParse
(or variants, e.g. double.TryParse
)
TryParse
returns a bool
, where true
indicates successful parsing.
Remarks:
- Avoid int.Parse
if you do not know if the value parsed is definitely a number.
- Avoid Convert.ToInt32
entirely, this is an older method and Parse
should be preferred where you know the string can be parsed.
Read more hereInteresting
"Avoid int.Parse if you do not know if the value parsed is definitely a number."
Isn't this unavoidable tho?
no
it's saying that if you aren't 100% sure the input string is a number, use TryParse instead
for user input you won't ever know for sure, but for other applications like reading files another program generated you can make assumptions
ooh i see
basically, you can use TryParse in an if instead of Parse in a try/catch and it's a bit nicer to look at and technically more efficient code
Hmm
I'm not too familiar with TryParse, woudl you be able advise me how it works?
foreach
might be more appropriate here but i've never used it before.
Either way, i want to Parse every item inside the string[] parts
now to it's appropriate type
Ok nvm i decided on an if, else if statement to work around it
thanks :catlove: