proposal: "throw?"

[TobiasKnauss]

The following code:

      var exception = CheckInputValue_ImageSize (i_sourceImageSize);
      if (exception != null)
        throw exception;

could be simplified as

   throw? CheckInputValue_ImageSize (i_sourceImageSize);

if there was an "throw?" command with the meaning "throw if not null".

[JasonBock]

Why would I return an exception from a method invocation? This seems like such a small corner case that it doesn't seem worth it to put time into adding this.

[svick]

Why do you use this pattern instead of directly throwing from CheckInputValue_ImageSize?

[foxesknow]

How common a use-case is it that you're been returned an exception which, if not null, you want to throw? I suspect it's almost zero.

[AlgorithmsAreCool]

Why would I return an exception from a method invocation?

Why do you use this pattern instead of directly throwing from CheckInputValue_ImageSize?

While I agree this is too niche to add to the language. It is a moderately common pattern to move exception creation into helper methods to either:

• Centralize exception logic
• Make the parent method more inline friendly

[PathogenDavid]

This is actually a pattern I've seen quite a bit. (It's an OK pattern for implementing a pair of TryXyz and Xyz methods when you don't care about the extra allocation of the exception in the TryXyz case.)

That being said, I agree with @AlgorithmsAreCool, this is pretty niche.

If you're finding yourself implementing this pattern a lot, I think you're better off making an internal extension method for Exception IE:

internal static class ExceptionExtensions
{
    [DoesNotReturn]
    // [StackTraceHidden] -- https://github.com/dotnet/runtime/issues/29681
    internal static void Throw(this Exception exception)
        => throw exception;
}

Then use it as:

CheckInputValue_ImageSize(i_sourceImageSize)?.Throw();

[TobiasKnauss]

@PathogenDavid : That's exactly what I need... if the [StackTraceHidden] attribute existed.
@AlgorithmsAreCool : Yes, I try to centralize the exception creation to avoid boilerplate code.
@svick This method calls other methods for more checks, and I prefer the exception to be thrown not in a 3rd-level check method, but rather in the method that should do the actual work, so you have a better understanding where it comes from.

Another reason for implementing this pattern: It's easier to write unit tests for these check methods. Instead of a try-catch in the unit test, you can just check the returned exception object.

[theunrepentantgeek]

I'll frequently create factory methods to create exceptions, but the logic controlling whether they throw will always be in the main method. Using factory methods, and moving exception instantiation out of the main flow of the method, gives room for better (more informative) exceptions.

So, I'd write the original code thusly:

if (!ImageSizeIsValid(i_sourceImageSize) 
{
    throw InvalidImageSizeError(i_sourceImageSize);
}

where the factory method might look something like this:

private InvalidOperationException InvalidImageSizeError(int imageSize) 
{
    var result = new InvalidOperationException($"Image size {imageSize} is invalid");
    result.Data[nameof(imageSize)] = imageSize;
    return result;
}

With respect to the original proposal, I don't believe a throw? keyword (or anything semantically similar, regardless of syntax) would be a good idea as it encourages poor design.

[TobiasKnauss]

I'll frequently create factory methods to create exceptions, but the logic controlling whether they throw will always be in the main method. Using factory methods, and moving exception instantiation out of the main flow of the method, gives room for better (more informative) exceptions.

I do use this approach at other places, but the problem is, that you'll have to double the logic if you want to provide additional information about what is wrong.
E.g. if the image size is checked against lower and upper limits, then the information, which limit was exceeded, must somehow be forwarded to the method that creates the exception. Thus it's easier for me to create the exception at the place where the check is done, and then just throw it if it exists.

[PathogenDavid]

@TobiasKnauss

That's exactly what I need... if the [StackTraceHidden] attribute existed.

The API was approved yesterday, so I like to hope it'll become available sooner rather than later.

[jnm2]

The API was approved yesterday, so I like to hope it'll become available sooner rather than later.

Can't it work to declare an internal attribute in the correct namespace in source, just like with all compiler-recognized attributes?

[PathogenDavid]

Can't it work to declare an internal attribute in the correct namespace in source, just like with all compiler-recognized attributes?

I was hoping so too. It's not a compiler thing, but the Visual Studio debugger does not appear to match it by shape either:

Additionally, StackTrace uses it directly, so it definitely needs the actual type.

[jnm2]

I wonder if they would accept a PR to match by full name rather than by metadata token.