A field of mutually exclusive bits.

Arnavion

@joe.edwards said:

Exceptions for flow control are just plain wrong.

Well I should have clarified.

Bad use of exceptions for flow control: @http://c2.com/cgi/wiki?DontUseExceptionsForFlowControl said:

void search( TreeNode node, Object data ) throws ResultException {
	if (node.data.equals( data ))
		throw new ResultException( node );
	else {
		search( node.leftChild, data );
		search( node.rightChild, data );
	}
}
The cute trick here is that the exception will break out of the recursion in one step no matter how deep it has got.

Good use of exceptions for flow control:


void SomeMethod()
{
	bool succeeded = DoStuff();
	if (!succeeded)
		throw new DoStuffFailedException("DoStuff");
succeeded = DoSomeMoreStuff();
if (!succeeded)
	throw new DoStuffFailedException("DoSomeMoreStuff");

}

and so on. You use exceptions to stop partway through the method when you realize there's no point in continuing. And instead of "goto cleanupcode;" you'd put this code in a try block and the cleanup code in the finally.

Of course it would be better if DoStuff() threw the exception itself, but sometimes you do have to interface with someone else's code/library.

Arnavion

@Ben L. said:

@Arnavion said:
If your language doesn't have exceptions (I'm looking at you, Go), then the only way is to have a "do X -> did X fail? -> early return with error code" block for each X.

Not exactly.

@Arnavion said:

Filed under: "We put exceptions in the language but we repeatedly warn you not to use them and that we'll hate you if you do", Cue someone correcting me that Go does have exceptions

error

@Ben L. said:

@Arnavion said:
If your language doesn't have exceptions (I'm looking at you, Go), then the only way is to have a "do X -> did X fail? -> early return with error code" block for each X.

Not exactly.

Defer sounds potentially neat. I wish morbs was around to point out the obvious pitfall I'm missing that makes it retarded.

HardwareGeek

@joe.edwards said:

@Ben L. said:
@Arnavion said:
If your language doesn't have exceptions (I'm looking at you, Go), then the only way is to have a "do X -> did X fail? -> early return with error code" block for each X.
Not exactly.
Defer sounds potentially neat. I wish morbs was around to point out the obvious pitfall I'm missing that makes it retarded.

IIRC, even Morbs said Go may have some good features hiding among the mountains of WTF (but not enough to be worth looking for them). Maybe you just found one.

error

@HardwareGeek said:

@joe.edwards said:
@Ben L. said:
@Arnavion said:
If your language doesn't have exceptions (I'm looking at you, Go), then the only way is to have a "do X -> did X fail? -> early return with error code" block for each X.

Not exactly.

Defer sounds potentially neat. I wish morbs was around to point out the obvious pitfall I'm missing that makes it retarded.
IIRC, even Morbs said Go may have some good features hiding among the mountains of WTF (but not enough to be worth looking for them). Maybe you just found one.

So, C# (and others) has the try { ... } finally { ... } construct to handle "must happen no matter what" type actions like cleaning up file handles (there's also using but it's semantic sugar for try...finally).

If the try block is lengthy, the cleanup code might be a screen or more away from the open code, so it's not immediately obvious at-a-glance if everything is being cleaned up. Also, opening multiple resources at once can lead to deeply indented blocks of code. Those are the downsides.

Go's defer statement solves both the issues of the cleanup code being separated from the resource acquisition, and the nesting issue. Go's approach, however, does not clean up resources until the end of the method (as far as I can tell), so if you only needed that file handle for a moment, you end up locking it for the duration of the method instead of only for the moment you actually were using it. This may be mitigated by refactoring.

I still have to award the point to C#, because the cons are mostly "it's ugly" and the pro is "finer grained control of when resources are freed."

Arnavion

@joe.edwards said:

If the try block is lengthy, the cleanup code might be a screen or more away from the open code, so it's not immediately obvious at-a-glance if everything is being cleaned up. Also, opening multiple resources at once can lead to deeply indented blocks of code. Those are the downsides.

Those are the downsides of using *try-finally*. "using" has none of those downsides, and is in fact better than Go because it doesn't have the issues you mention later in Go's way.

try-finally gives you more flexibility because you can do anything you want in the finally, rather than being restricted to calling Dispose(). You can have logging, for example. But the Go way of doing that would be worse, because you'd have to write the contents of your would-be-finally block in reverse order. So defer file.Close() goes first, then defer log("Something went wrong."), etc. which is worse for readability.

error



using( var dbConnection = Factory.GetConnection() ) {

if( dbConnection == null ) throw new Exception();

using( var cmd = new SqlCommand( "sp_FooBar", dbConnection ) ) {

using( var fileOutput = File.Open( @"Foo" ) ) {

using( var sw = new StreamWriter( fileOutput ) ) {

using( var reader = cmd.ExecuteReader() ) {

while( reader.Read() ) {

sw.WriteLine( reader.GetString( 0 ) );

}

reader.Close();

}

sw.Flush();

sw.Close();

}

fileOutput.Close();

}

}

dbConnection.Close();

}

Nope, using doesn't suffer from the indention problem at all.

DescentJS

@Arnavion said:

@joe.edwards said:
If the try block is lengthy, the cleanup code might be a screen or more away from the open code, so it's not immediately obvious at-a-glance if everything is being cleaned up. Also, opening multiple resources at once can lead to deeply indented blocks of code. Those are the downsides.

Those are the downsides of using *try-finally*. "using" has none of those downsides, and is in fact better than Go because it doesn't have the issues you mention later in Go's way.
try-finally gives you more flexibility because you can do anything you want in the finally, rather than being restricted to calling Dispose(). You can have logging, for example. But the Go way of doing that would be worse, because you'd have to write the contents of your would-be-finally block in reverse order. So defer file.Close() goes first, then defer log("Something went wrong."), etc. which is worse for readability.

it's even worse than that, you'd have to specifically check in the defered function whether you're panicking or not, and then react to it in the event of something going wrong. The even worse bit about this is that if you want something like a stack trace you have to specially design your panic codes to encode the stack trace into it. So GO manages to have all the inconveniences of error codes, while also having most of the inconveniences of exceptions too. It's like the designers looked at existing languages and tried to take only the parts that produced the worst designs.

Sutherlands

Despite your nice coding of doing a billion things in one function...

@joe.edwards said:

using( var dbConnection = Factory.GetConnection() ) 
{
    if( dbConnection == null ) 
        throw new Exception();
using( var cmd = new SqlCommand( "sp_FooBar", dbConnection ) )
using( var fileOutput = File.Open( @"Foo" ) )
using( var sw = new StreamWriter( fileOutput ) )
using( var reader = cmd.ExecuteReader() )
{
    while( reader.Read() ) {
        sw.WriteLine( reader.GetString( 0 ) );
}

}

Nope, using doesn't suffer from the indention problem at all.

FTFY

error

@Sutherlands said:

Despite your nice coding of doing a billion things in one function...

*gasp* You mean my example code to illustrate a possible problem is not best practice?

I've also been bitten by Dispose methods that didn't fully finalize, like an IO class that would just close the handle on Dispose without Flushing the output buffer, so the output was truncated - which is why I had that Flush call in there.

Might not be required here, but once bitten twice shy.

Arnavion

@joe.edwards said:

using( var dbConnection = Factory.GetConnection() ) {

if( dbConnection == null ) throw new Exception();

using( var cmd = new SqlCommand( "sp_FooBar", dbConnection ) ) {

using( var fileOutput = File.Open( @"Foo" ) ) {

using( var sw = new StreamWriter( fileOutput ) ) {

using( var reader = cmd.ExecuteReader() ) {

while( reader.Read() ) {

sw.WriteLine( reader.GetString( 0 ) );

}

reader.Close();

}

sw.Flush();

sw.Close();

}

fileOutput.Close();

}

}

dbConnection.Close();

}

Nope, using doesn't suffer from the indention problem at all.

I don't think you've ever used using.

@FTFY said:

using( var dbConnection = Factory.GetConnection() ) {

using( var cmd = new SqlCommand( "sp_FooBar", dbConnection ) )

using( var fileOutput = File.Open( @"Foo" ) )

using( var sw = new StreamWriter( fileOutput ) )

using( var reader = cmd.ExecuteReader() )

while( reader.Read() ) {

sw.WriteLine( reader.GetString( 0 ) );

}

The whole point of using is that those explicit Close() are not there. And if you use the default C# formatting (aka everything VS does) then you'll notice using's don't get indented for exactly this reason.

@Sutherlands said:



using( var dbConnection = Factory.GetConnection() )

{

if( dbConnection == null )

throw new Exception();

I think that's a superfluous null-check. I'm not near a compiler right now but I'm pretty sure if Factory.GetConnection() returns null the using will throw an NPE. I might be wrong though.

Arnavion

@joe.edwards said:

I've also been bitten by Dispose methods that didn't fully finalize, like an IO class that would just close the handle on Dispose without Flushing the output buffer, so the output was truncated - which is why I had that Flush call in there.

A genuine concern. But if I were in your position I'd drop back to using try-finally. Having both would-be-in-a-finally-block code and a using smells.

boomzilla

@Arnavion said:

@FTFY said:
using( var dbConnection = Factory.GetConnection() ) { using( var cmd = new SqlCommand( "sp_FooBar", dbConnection ) ) using( var fileOutput = File.Open( @"Foo" ) ) using( var sw = new StreamWriter( fileOutput ) ) using( var reader = cmd.ExecuteReader() ) while( reader.Read() ) { sw.WriteLine( reader.GetString( 0 ) ); }
And if you use the default C# formatting (aka everything VS does) then you'll notice using's don't get indented for exactly this reason.

That seems like a bad idea. I also hate omitted brackets, though I suppose I could live with an exception when you "chain" usings like this. But why would you want brackets to look differently here? Doesn't this also make the scope less obvious? Maybe it only does this when you have usings on consecutive lines? The positioning of "while " in your example seems to say so.

That aside, I like the RAII-ness of using. It seems like a pretty reasonable hack around the nature of the GC.

Arnavion

@boomzilla said:

Maybe it only does this when you have usings on consecutive lines? The positioning of "while " in your example seems to say so.

That is correct. It's a special case in Visual Studio's indentation rules for consecutive using statements.

Sutherlands

@Arnavion said:

I think that's a superfluous null-check. I'm not near a compiler right now but I'm pretty sure if Factory.GetConnection() returns null the using will throw an NPE. I might be wrong though.

It won't. It will probably throw a NRE in new SqlCommand, or somewhere else down the line... but code throwing a NRE is a bug in the code. Instead it should throw a more descriptive error.

Also, read the tags.

Sutherlands

@joe.edwards said:

*gasp* You mean my example code to illustrate a possible problem is not best practice?

Yes. Point being that you don't have indention problems if you don't have so many usings.

@joe.edwards said:

I've also been bitten by Dispose methods that didn't fully finalize, like an IO class that would just close the handle on Dispose without Flushing the output buffer, so the output was truncated - which is why I had that Flush call in there.

Might not be required here, but once bitten twice shy.

I double-checked that Dispose calls Flush and Close for those methods. Of course there can be a bug in a library, but I wouldn't put those in unless we found a bug.

Ronald

@boomzilla said:

It seems like a pretty reasonable hack around the nature of the GC.

The greatest hack around the nature of the GC is IIS recycling worker processes. This works well because it is a scaled-down version of the system resources deallocation sequence as defined in page 1 of the Microsoft Maintenance Manuel (aka "reboot").

Arnavion

@Sutherlands said:

It won't. It will probably throw a NRE in new SqlCommand, or somewhere else down the line.

Just tried it out on a compiler and I stand corrected. I thought using's had a null check on their value (because how else would they call Dispose() on whatever they have) but apparently they don't.