Optional out parameters?

[Paul E Collins]

This is just a suggestion.

When a method has an out parameter, the calling code has to supply a
target variable. I would like to be able to pass null instead,
indicating that I have no use for the out parameter.

For example, if I have a method ...
bool IsValidWeight(float weight, out string error)
.... I might want to check whether a weight is valid without caring
about the specific error ("value is negative", "value is too high",
etc.), in which case declaring and passing the unused variable seems
to complicate the code unnecessarily.

What do you think?

P.

 

[Nicholas Paldino [.NET/C# MVP]]

Paul,

I am not too sure I like it, only because it looks odd when the
signature is a value type, like this:

bool InvalidWeight(float weight, out int error);

Then the use of null is non-intuitive, and would be a detriment to the
language, IMO.

 

[Bruce Wood]

In C# you achieve this by providing an alternate method signature,
without the offending out argument.

The alternate implementation can then just declare the out argument,
pass it to the full method implementation, and simply not return that
argument.

 

[Jon Skeet [C# MVP]]

This is just a suggestion.

When a method has an out parameter, the calling code has to supply a
target variable. I would like to be able to pass null instead,
indicating that I have no use for the out parameter.

For example, if I have a method ...
bool IsValidWeight(float weight, out string error)
... I might want to check whether a weight is valid without caring
about the specific error ("value is negative", "value is too high",
etc.), in which case declaring and passing the unused variable seems
to complicate the code unnecessarily.

What do you think?

Probably the easiest way of doing this is overloading the method, so
you also provide:

bool IsValidWeight (float weight)
{
string error;
return IsValidWeight (weight, out error);
}

(Note that exceptions would usually be a better way of indicating
errors.)

 

[sadhu]

AFAIK there is no other way than providing another overload for
IsValidWeight without the out parameter.

 

[sadhu]

AFAIK, there is no way except providing another overload for
IsValidWeight that doesn't have the out parameter.

 

[Nicholas Paldino [.NET/C# MVP]]

I don't agree here. I think that for errors in what is classified as
"business logic", exceptions are not appropriate. Exceptions should be used
to handle the exceptional case, IMO. This kind of thing is not exceptional,
and has to be guarded against, but your app doesn't have to be blown out of
the water as a result.

In other words, exceptions shouldn't be used for recoverable operations,
IMO.

 

[Guest]

Paul,

I am not too sure I like it, only because it looks odd when the
signature is a value type, like this:

bool InvalidWeight(float weight, out int error);

if you think of "out int" or "ref int" as int*, then it's not THAT weird.

something like this would be somewhat useful when you do p/invoke. I've
seen api where pass in null to int* to indicate ignore output.

Then the use of null is non-intuitive, and would be a detriment to the
language, IMO.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This is just a suggestion.

When a method has an out parameter, the calling code has to supply a
target variable. I would like to be able to pass null instead, indicating
that I have no use for the out parameter.

For example, if I have a method ...
bool IsValidWeight(float weight, out string error)
... I might want to check whether a weight is valid without caring about
the specific error ("value is negative", "value is too high", etc.), in
which case declaring and passing the unused variable seems to complicate
the code unnecessarily.

What do you think?

P.

 

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

There it would be helpful, but that hopefully will be resolved with the
introduction of nullable types. Hopefully we will see the P/Invoke layer
and COM interop use them for situations like this.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Paul,

I am not too sure I like it, only because it looks odd when the
signature is a value type, like this:

bool InvalidWeight(float weight, out int error);

if you think of "out int" or "ref int" as int*, then it's not THAT weird.

something like this would be somewhat useful when you do p/invoke. I've
seen api where pass in null to int* to indicate ignore output.

Then the use of null is non-intuitive, and would be a detriment to
the
language, IMO.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

This is just a suggestion.

When a method has an out parameter, the calling code has to supply a
target variable. I would like to be able to pass null instead,
indicating
that I have no use for the out parameter.

For example, if I have a method ...
bool IsValidWeight(float weight, out string error)
... I might want to check whether a weight is valid without caring
about
the specific error ("value is negative", "value is too high", etc.), in
which case declaring and passing the unused variable seems to
complicate
the code unnecessarily.

What do you think?

P.

 

[Jon Skeet [C# MVP]]

I don't agree here. I think that for errors in what is classified as
"business logic", exceptions are not appropriate. Exceptions should be used
to handle the exceptional case, IMO. This kind of thing is not exceptional,
and has to be guarded against, but your app doesn't have to be blown out of
the water as a result.

In other words, exceptions shouldn't be used for recoverable operations,
IMO.

It's one of those things which very much varies by taste. One of the
things I like about exceptions is that I can't just ignore them absent-
mindedly. It's very easy to forget to check an out parameter or a
return value - but forgetting to handle an exception is harder, so you
don't tend to proceed with something without getting the prerequisites
right. (Your program may crash, but it won't overwrite good data with
bad, for instance.)

 

[Jeff Louie]

Nicholis... I really like an explicit version of Henry Sutter's
approach. If the
method explicitly documents a precondition, then, if possible, the
method
throws an exception if the pre-condition is violated. This is
independent of
the presence of a recoverable operation. Thus two identical methods can
have
different behaviors, based on the explicity documented pre-conditions.
If a
pre-condition is declared, then the caller must validate the
pre-condition. So
if a a file must exist as a precondition, then the caller calls if
(File.Exist(myFile) or the method may throw an exception. If the the
method
does not declare that the file must exist as a precondition, then if the
file
dose not exist, the method does _not_ throw an exception. Instead it may
return say null.

Regards,
Jeff

In other words, exceptions shouldn't be used for recoverable

operations,
IMO.<

 

[Christoph Nahr]

In other words, exceptions shouldn't be used for recoverable operations,
IMO.

I believe the C# design disagrees with you here, since the "catch"
keyword seems pretty much designed to deal with recoverable errors.