Discussion: throw a string

[epa]

Exception classes are great, but sometimes in short scripts you want to just die with an error message. It gets a bit clunky to keep writing

throw new Exception("argh");

when it would be more concise to just

throw "argh";

When the value following throw is a string, this should be a shortcut for making a new Exception object with that string.

[theunrepentantgeek]

Generally speaking, throwing Exception is considered poor practice because it prevents any/all consumers from doing anything specific with that one exception.

Visual Studio includes an explicit code analysis rule to this effect (CA2201):

The following exception types are too general to provide sufficient information to the user:
System.Exception
System.ApplicationException
System.SystemException

Someone asked about this on Stack Overflow, where the top answer says:

Exception is the base type for all exceptions, and as such terribly unspecific. You shouldn’t ever throw this exception because it simply does not contain any useful information. Calling code catching for exceptions couldn’t disambiguate the intentionally thrown exception (from your logic) from other system exceptions that are entirely undesired and point out real faults.

I know that @epa, you're suggesting this for scripts (emphasis added):

Exception classes are great, but sometimes in short scripts you want to just die with an error message.

However, the kind folks on the LDM have made it clear that they never want to go down the route of creating different dialects of C# for different uses - the one C# language has to handle all situations. This means there's no way to support this idea for scripting (where it might just possibly be defensible) without also permitting it for the vast body of code where it would have a lot of bug-inducing consequences.

What I've done in situations like this is to create a helper method that makes things more concise:

throw Error("It's dead, Jim");

private Exception Error(string message)
    => new InvalidOperationException(message);

[epa]

I don't see how it would have bug-inducing consequences when you can already just throw new Exception. Unless you propose to forbid that too.

I see it more along the lines of array initializer expressions, where C# has a useful shortcut for something that would otherwise require you to use a scripting language instead. (And there was a time when initializing arrays of data inside the program body was subject to a lot of moral disapproval, because obviously in a robust application you should separate code and data...)

[DavidArno]

Issue #538, Proposal: never/bottom type, offers a possible solution here, if it were ever implemented. You'd be able to write, eg a method like:

Never Die(string reason) => throw new Exception(reason);

and then use it in place of an explicit throw and still have the compiler know that the method doesn't return:

double Divide(double a, double b) => b != 0.0 ? a/b : Die("Cannot divide by zero");

[epa]

P.S. it would also be possible to define a specific exception class for this syntax, so that throw "argh" becomes equivalent to

throw new UserStringException("argh")

Then you'd comply with the rules about not throwing Exception directly, and if somehow your hacked-up bit of script does end up being called as part of a larger application (I know...) it would still be possible to distinguish between these exceptions and system-generated ones.

In fact, it would be a small improvement in robustness, since people who currently have to type throw new Exception would change to just throw instead and get the slightly more specific type... while being happy that their code is no longer so verbose.

[CyrusNajmabadi]

in short scripts you want to just die with an error message.

If this is your goal, then define your own Exit function that does:

Console.WriteLine(message);
Environment.Exit(exitCode);

Then just call Exit("whatever") when you want to die. There's no need to change the language here.

[Scott-Caldwell]

In fact, it would be a small improvement in robustness, since people who currently have to type throw new Exception would change to just throw instead and get the slightly more specific type... while being happy that their code is no longer so verbose.

I'm not sure that that would be much more robust. UserStringException would just become the new Exception.

One real advantage of throwing explicit exceptions is how you can convey information about what went wrong simply by throwing an exception of a specific type. For example, if I encounter an ArgumentNullException, I know exactly why the program failed - an argument was null when it was expected to be non-null, and it even tells me which argument was null.

In contrast, UserStringException gives me no way of knowing what happened without reading the string. If I have to read the string manually, I can't write any case-specific logic based on the exception. I dare not try to parse the string contained in the exception (what if it's localized?). I'm not sure what I'd do with such an exception except maybe display an error message and exit, in which case Cyrus's suggestion seems like a good alternative that doesn't require a change to the language.

This just feels like it's going to promote the otherwise discouraged practice of throwing nonspecific exceptions.

[epa]

Thanks for your comments. Of course I absolutely agree that parsing exception strings is horrible garbage. If you want to catch the exception and handle it, it's far cleaner to have different exception types.

What I suspect some may be missing is that I'm talking explicitly about exceptions you don't want to catch. Most likely this is in a standalone program (not part of a long-running server process, and not with a GUI) where you check for various error conditions and just need to abort the whole process and print a stack trace. These are programs where you'd often reach for a scripting language such as Perl with its handy die. Over the years C# has acquired lots of useful shortcut features such as var which have made it more usable for this kind of one-shot programming -- and every one of those features has code quality arguments that can be made against it.

Another use is for 'impossible' conditions where if the throw is hit, it indicates a programmer error. You can use Debug.Assert for these but it only fires in debug builds. To my mind, it increases code quality to give the programmer a quick, robust way to bail out on error conditions that indicate a logic error. Make it easy to do so, without unnecessary boilerplate, and more programmers will.

[Joe4evr]

To my mind, it increases code quality to give the programmer a quick, robust way to bail out on error conditions that indicate a logic error.

I think exceptions are a robust enough mechanism to convey the error that a programmer encountered. Additionally, you can ship analyzers that will warn/error programmers when they write code that you know would produce runtime errors.

[epa]

I think exceptions are a robust enough mechanism to convey the error that a programmer encountered.

Yes, they are! Much better than printing a message and calling System.Exit() or whatever. That's why I think a bit of syntactic sugar would go down well to encourage use of exceptions (rather than ad-hoc message printing) in prototypes and standalone scripts.

[CyrusNajmabadi]

What I suspect some may be missing is that I'm talking explicitly about exceptions you don't want to catch. Most likely this is in a standalone program (not part of a long-running server process, and not with a GUI) where you check for various error conditions and just need to abort the whole process and print a stack trace.

You can do this. I already showed how above :). The code i listed will do all you want, besides printing the stack trace. But if you want that, it's trivial for you to add it. I don't see wy you need any language features here since you could just just make this a trivial library function that you could then use from anywhere in your app.

[epa]

Thanks CyrusNajmabadi. I should have realized that printing a stack trace is also something that can be done easily from the library function.

[CyrusNajmabadi]

yup yup! :)

[orthoxerox]

Being able to throw something other than an exception would be a nice way of implementing non-local control flow without sacrificing performance.

[ahdung]

I support this. simplicity is justice.

[GeirGrusom]

Does this require a CLR change? I see mention that apparently a conforming runtime can allow throwing, and catching, non-exception based objects, but it seems to me that it isn't required by a CLS conforming runtime to support it?

[Joe4evr]

@GeirGrusom Not inherently. The CLR already permits throwing any object type. When you use await in a catch or finally block for example, the generated IL will throw an int to represent the state the state machine should be in once the Task is completed.

[Austin-bryan]

@theunrepentantgeek

I was going to suggest using an alias, but yours is even better. Really elegant solution.

[OyasumiLad]

It would be possible if we'll ever get something like extendable implicit operators..

The closest thing you can currently get to fulfill your desire for the least amount of keystrokes is probably something like this:

static class IAmTooLazyToWriteThrowNew
{
    static class Exceptions<T> where T : Exception
    {
        public static Exception New(string message) => (Exception)Constructor?.Invoke(new[] { message }) ?? new Exception(message);

        static ConstructorInfo Constructor = typeof(T).GetConstructors().Where(info =>
        {
            var param = info.GetParameters();
            return param.Length == 1 && param[0].ParameterType == typeof(string);
        }).FirstOrDefault();
    }

    // Under a release build the site of the exception would be the method which called this (hopefully).
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void Throw<T>(this string message) where T : Exception => throw Exceptions<T>.New(message);

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void Throw(this string message) => Throw<Exception>(message);
}

And then calling it like so:

"It's all over".Throw();
"It's all over, but at least you get a hint".Throw<ArgumentException>();

This isn't really that useful though.

What is useful, is extendable implicit operators, can we get those please?