Quick rant: why isn't there an Exception(string, params object[]) constructor?

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Sat, 07 Feb 2009 20:44:56 GMT

@Peter: I'm pretty sure (though I haven't checked) that the rules for picking the "best" method would do the right thing there.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Peter Morris — Sat, 07 Feb 2009 20:42:20 GMT

I presume the constructor would look like this

Exception(string message, params object[] values)

If so, how would this work?

try

{

throw InvalidOperationException();

}

catch(Exception e)

{

throw new MyException(e.Message, e);

}

Is "e" a format value, or an inner exception?

:-)

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

David Nelson — Fri, 30 Jan 2009 16:30:41 GMT

Language support would be nice, although C# is already getting too close to C++ - like complexity for my taste.

@Cedric

Phil Haack just wrote a couple of posts on "Named Format Strings" which explores that topic in C# (haacked.com/.../fun-with-named-formats-string-parsing-and-edge-cases.aspx)

re: string interpolation

Cedric — Fri, 30 Jan 2009 05:26:39 GMT

In some .NET programming languages, at least in Boo ( http://boo.codehaus.org/ ), there is string interpolation expressions, which allows for any string:

"Expected to read ${requiredSize} bytes but only ${bytesRead} were available"

Easy to use (moreso than Python's %) and easy to read.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Wed, 28 Jan 2009 06:29:11 GMT

@David: I agree there's a line to be drawn, and that it would be a pain to have the overloads everywhere. I just find myself wanting it so often that it annoys me.

Perhaps, as Steve Cooper says, the answer isn't to change all the methods, but to give language support for string.Format. Hmm.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

David Nelson — Wed, 28 Jan 2009 00:36:05 GMT

Convenience is one thing, but where do you draw the line? Like I said, I don't want to see every single method in the framework which takes a string overloaded to also take a format string. If that's not what you're advocating, then I guess I don't see why you think that this particular overload is any more useful than any other method anywhere in the framework that takes a string. Especially since it would have to duplicated in every single Exception class to have any real value.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Tue, 27 Jan 2009 06:39:42 GMT

@David: Simply for the sake of convenience. We do plenty of things for the sake of convenience - adding a couple of overloads to places where they're going to be really, really useful seems appropriate to me.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Da vid Nelson — Tue, 27 Jan 2009 00:30:48 GMT

@Jon,

No, I don't explicitly call Format when using Console.WriteLine, but only because the overload is already there, so I might as well use it. That is not the same thing as saying that I think it was worth creating that overload in the first place. Why create the extra maintenance overhead to every method which takes a string, when String.Format is already documented and well known?

Quick rant: why isn't there an Exception(string, params object[]) constructor? - Jon Skeet: Coding Blog

DotNetShoutout — Mon, 26 Jan 2009 06:34:23 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

python-style string formattin for c#

Steve Cooper — Sat, 24 Jan 2009 19:32:01 GMT

You got me thinking about ways to make String.Format work more easily; if String.Format wasn't so intrusive in the code, (say, if it were like python's format,) then it wouldn't be an issue.

An example solution (and a fantastic abuse of programming in unicode) can be found here;

www.stevecooper.org/.../python-style-string-formatting-for-c

Steve Cooper » Blog Archive » Python-style string formatting for C#

Steve Cooper » Blog Archive » Python-style string formatting for C# — Sat, 24 Jan 2009 19:28:19 GMT

Pingback from Steve Cooper » Blog Archive » Python-style string formatting for C#

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Chris Nahr — Sat, 24 Jan 2009 16:55:20 GMT

No problem, and I'm not saying you're guaranteed vast performance improvements or anything, just that this particular micro-optimization is about as simple and harmless as it gets, so if you start anywhere you might as well start here. :)

Good point about switch/case statements, the C# compiler unfortunately can't figure out that a ThrowHelper method won't return (and I couldn't find a method attribute to that effect), so you would need an extra break/return statement.

As for the implementation, I'm not using any generics, just a separate method for every exception type and possible argument combination I want to throw. That's also how the BCL implements ThrowHelper, by the way. There actually aren't all that many common types -- Argument/Null/OutOfRange and InvalidOperation cover most possibilities. Throw in some I/O-related and application-specific exceptions, and you're pretty much done.

The syntax follows the statement syntax, e.g. ThrowHelper.ThrowArgumentException. I'm adding a ...WithFormat to the name for overloads that specify a format string with formatting arguments because I found that the overloads can get too confusing otherwise. Of course that's a question of personal taste.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Sat, 24 Jan 2009 15:21:57 GMT

@Chris: Having given my skeptical view, I will try it for protocol buffers, where efficiency really is important and inlining could make a significant difference. I don't mean to seem ungrateful in my comments :)

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Sat, 24 Jan 2009 12:47:12 GMT

It's not as easy to read, because it's something else to learn that's non-standard. Everyone knows what a throw statement does - and that includes the compiler, which knows that execution won't go beyond it. (Think about the end of a switch case, for example.)

How do you throw an arbitrary exception with a message in ThrowHelper? Does it use generics and reflection together for speed and assume the exception will have the appropriate constructor? Or do you have one method for each type of exception you want to throw?

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Chris Nahr — Sat, 24 Jan 2009 10:42:57 GMT

Given that a ThrowHelper call is about as easy to write and read as an explicit throw statement, I don't really see why you would ever not want to save those 30-60 bytes of machine code per occurrence. It's not like you're introducing a complex reformulation of an algorithm -- it's usually a simple textual replacement, one statement vs one method call.

Once I had realized how costly throw is, I just replaced throw with ThrowHelper everywhere. There's no downside, you make your binary image smaller, and the JITter gets new chances at inlining -- what's not to like?

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Sat, 24 Jan 2009 10:04:51 GMT

With the added benefit of formatting (and anything else useful, such as nullity checking etc) I can see an argument for using a ThrowHelper all over the place. The performance argument doesn't sway me for anything other than performance-critical code, where micro-optimisation is more reasonable. It's nice to know, for the sake of those few places where performance really *is* that important, but I'm happy to leave it to those places.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Chris Nahr — Sat, 24 Jan 2009 09:52:32 GMT

Jon, the fundamental issue is that a throw statement translates into a surprisingly large amount of machine code. Checking the JITter output for both platforms (32/64 bit) and compiler modes (debug/release) on .NET 3.5 SP1, I counted between 30 and 60 extra bytes compared to an equivalent ThrowHelper call.

For one thing, that's going to bloat your code image significantly if you carefully guard all your arguments etc., as the entire rest of a short method is often shorter than the output for a single throw.

For another thing, the extra size is going to prevent inlining of short methods. I quickly found a test case for getter-sized methods where a ThrowHelper variant would get inlined but the throw variant would not.

The 2nd ed. of the "Framework Design Guidelines" also recommends using exception builder methods for this reason (page 220f), although they incorrectly claim that throw code never gets inlined (it does, it's just often too big). And if you look through the BCL with Reflector you'll find that Microsoft used ThrowHelper calls all over the place, in preference of throw statements.

Also, I hear some people want string formatting with their exceptions, and a ThrowHelper class is a convenient place for that functionality. :)

Another thought regarding String.Format: you should generally specify an explicit IFormatProvider (usually either CurrentCulture or InvariantCulture). What should the implicit formatting culture be for that hypothetical formatting constructor provided by the exception? Wouldn't you need yet another ctor that also takes an IFormatProvider? That's another argument for custom ThrowHelper methods, since you just specify the desired IFormatProvider in one place.

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Sat, 24 Jan 2009 09:23:59 GMT

@Chris: Could you explain your reasoning for the "ThrowHelper" class? It sounds like another level of indirection for no good reason, unless it makes a *huge* performance gain. What kind of thing is in there, and what difference does it make?

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Serge Wautier — Sat, 24 Jan 2009 08:54:13 GMT

My quick rant:

why isn't there Debug.WriteLine(string, params object[]) ?

re: Quick rant: why isn't there an Exception(string, params object[]) constructor?

Vincent Croquette — Sat, 24 Jan 2009 08:51:17 GMT

I think Jesper's has a point

Formatting strings is a very common need, so common that shortcuts were sometimes implemented (Console.WriteLine...)

Do you remember the time where we had to implement iterators the hard way (prior to yield return)?

The C# team was smart enough to realize that yield was a very handy tool and decided to include it in the language. Same could apply here