Hacker News Reader

Comment by sirmarksalot | Hacker News Reader

Another example: a lot of old code bases use "goto" for error handling. I'm assuming the Linux kernel still does this. Now we've formalized that behavior into exceptions.

View on HN

Formalized that behavior into exceptions? Last I checked using exceptions for control flow was a BAD practice.

In c at least, breaking out of an error condition is still best handled with a goto (where you can clean up all matter of memory in an organized fashion without littering your code with if elses).

This discussion sort of hinges on being able to explain why something is a bad practice or not. What problems in particular do exceptions cause, and in which situations do they not apply? In other words, is it ever right to throw an exception, or is every line of code in your program "control flow?"

It's been nearly a decade since I've used plain C, so I'm not 100% sure, but I was under the impression that it doesn't have any native support for exceptions. So yes, under those circumstances "goto" would definitely be appropriate.

In C#, you can implement resource ownership with the IDisposable interface and "using" keyword, which guarantees that once you leave the block (via an exception or regular control flow), the resource is cleaned up. In C++, you can use the RAII pattern that another commenter brought up. What other problems do exceptions introduce?

In my as-functional-as-is-practical programming philosophy, you throw an exception when there is no valid output for your function. Whether or not that's recoverable is up to the client to decide. Nulls are an extremely poor substitute for this, as they push the responsibility of output validation onto the client, and every single line of code must be enclosed in an "if (foo != null)" block.

EDIT: Removed unproductive "zinger" at end.

You need C++'s RAII idiom or go's defer syntax to get the same behaviour though. I think try-with-resource in Java also would do the same thing, maybe. Just plainly throwing an exception won't release what you've acquired.

Something like go's defer makes most uses of goto (failure handling) unnecessary. However, there is still the "code a state machine" use case for goto.

Which we are trying to eliminate with tail-call-optimized mutually recursive functions.

Which are semantically less clear than goto, when you are working with something that is semantically a state machine.

Actually, I think that mutually-recursive functions are more semantically clear than goto for a state machine, though using explicit state objects is even more clear than either (though probably less efficient.)

ensure: blocks were how it was done in Smalltalk. You simply had a block of code that was followed by another block of code that the system would ensure the execution of. There was slightly more to it. You had to make sure that whatever ran in that block wouldn't take too long to complete, for example.

Reply on news.ycombinator.com