4 ms·

This seems like a solution looking for a problem. There is a whole class of code smell around using exceptions to direct logic flow. The only thing this does th

This seems like a solution looking for a problem. There is a whole class of code smell around using exceptions to direct logic flow. The only thing this does that can't be done with if statements and delegates is lower the importance of exceptions from "definitely an error" to "maybe an error, maybe normal behavior". Maybe there are less contrived examples that better show off what this feature could do, but it still smells fishy to me. Edit: I realize that Java doesn't have delegates, but I would say that's a point against Java, not a point in favor of this method.

deleted 15y ago
[deleted]
tomp 15y ago
That's one way to look at it, and it certainly is valid, to some extent. Another way to look at it is that exceptions are fundamentally limited, and conditions provide a whole new sea of possibilities. His example is rather awkward and actually confuses the reader, rather than excites. The point of conditions actually is to allow flexibility without all the if statements and delegates. His final getVal() function should look like this Object getVal() { try { if (val == null) throw new NoValException(); else return val; } catch (UseValRestart r) { return r.getVal(); } } and the high-level code should handle how the value is provided (either some specific value, user input, web request, random bits, etc...). So, one only has to write the code for getVal() once and can customize it indefinitely.
arebop 15y ago
Maybe you think Null Object Pattern or Maybe Monad are better ways to deal with the article's motivating example problem. What about dealing with network errors by exponential backoff and retry? What about the ask-the-user-what-to-do policy the author mentions? I'm not sure what you mean by delegates, but it sounds like you're saying that you don't need special syntax for conditions when you have first-class functions and simpler control-flow primitives. True, but sugar is nice sometimes; I'd often rather have a list comprehension than a pile of gotos and assignments.
- Total_Meltdown 15y ago
  Yes, first-class functions are what I mean. (I come from a lot of C# development, where functions-as-variables are called delegates.) As for sugar, I agree that it's nice sometimes, but I disagree with extending exception handling specifically. Exceptions are for errors, such as sending data over a closed stream, or indexing an array out of bounds. This "condition system" pattern encourages using exceptions for logic flow. Because why pass a function all the way down the call stack when you can just throw an exception to request that data from higher in the call stack, right? Exceptions are errors, and they should be treated as such in all cases.
  - true_religion 15y ago
    >Exceptions are errors, and they should be treated as such in all cases. This sounds an awful lot like a semantic argument. If you have resumable exceptions, and can raise an exception deep in the stack to ask higher-stack callers for more information then that's an query. If you raise an exception in non-exceptional circumstances then that's a scoped announcement. The mere fact that in some languages they use the same run-time hooks as exceptions is irrelevant. Exceptions, where I first learned of them in Smalltalk derive from a prototype class that isn't named Exception, and I've seen all manner of uses of the same machinery in stack-twisting. After all once you have full closures, and full control over your stack and context why shouldn't you use it for higher order abstractions involving the stack-context?
pygy_ 15y ago
Another valid and mysteriously killed post. When are the admins going to do something about this? ---- in [1], tomp [2] posted: That's one way to look at it, and it certainly is valid, to some extent. Another way to look at it is that exceptions are fundamentally limited, and conditions provide a whole new sea of possibilities. His example is rather awkward and actually confuses the reader, rather than excites. The point of conditions actually is to allow flexibility without all the if statements and delegates. His final getVal() function should look like this Object getVal() { try { if (val == null) throw new NoValException(); else return val; } catch (UseValRestart r) { return r.getVal(); } } and the high-level code should handle how the value is provided (either some specific value, user input, web request, random bits, etc...). So, one only has to write the code for getVal() once and can customize it indefinitely. ---- [1] http://news.ycombinator.com/item?id=2683678 http://news.ycombinator.com/item?id=2683678 [2] http://news.ycombinator.com/user?id=tomp http://news.ycombinator.com/user?id=tomp
- Total_Meltdown 15y ago
  I understand what the intent is, and I think it could be a useful mechanism, but as I've said in other posts, I disagree that exceptions are the way to go about it. I think something similar to exceptions, but intended for this kind of indirection would be good. But I'm strongly of the opinion that all exceptions should be treated as problems to be fixed, not just another pattern.

deleted 15y ago

[deleted]

tomp 15y ago

That's one way to look at it, and it certainly is valid, to some extent. Another way to look at it is that exceptions are fundamentally limited, and conditions provide a whole new sea of possibilities. His example is rather awkward and actually confuses the reader, rather than excites. The point of conditions actually is to allow flexibility without all the if statements and delegates. His final getVal() function should look like this Object getVal() { try { if (val == null) throw new NoValException(); else return val; } catch (UseValRestart r) { return r.getVal(); } } and the high-level code should handle how the value is provided (either some specific value, user input, web request, random bits, etc...). So, one only has to write the code for getVal() once and can customize it indefinitely.

arebop 15y ago

Maybe you think Null Object Pattern or Maybe Monad are better ways to deal with the article's motivating example problem. What about dealing with network errors by exponential backoff and retry? What about the ask-the-user-what-to-do policy the author mentions? I'm not sure what you mean by delegates, but it sounds like you're saying that you don't need special syntax for conditions when you have first-class functions and simpler control-flow primitives. True, but sugar is nice sometimes; I'd often rather have a list comprehension than a pile of gotos and assignments.

Total_Meltdown 15y ago
Yes, first-class functions are what I mean. (I come from a lot of C# development, where functions-as-variables are called delegates.) As for sugar, I agree that it's nice sometimes, but I disagree with extending exception handling specifically. Exceptions are for errors, such as sending data over a closed stream, or indexing an array out of bounds. This "condition system" pattern encourages using exceptions for logic flow. Because why pass a function all the way down the call stack when you can just throw an exception to request that data from higher in the call stack, right? Exceptions are errors, and they should be treated as such in all cases.
- true_religion 15y ago
  >Exceptions are errors, and they should be treated as such in all cases. This sounds an awful lot like a semantic argument. If you have resumable exceptions, and can raise an exception deep in the stack to ask higher-stack callers for more information then that's an query. If you raise an exception in non-exceptional circumstances then that's a scoped announcement. The mere fact that in some languages they use the same run-time hooks as exceptions is irrelevant. Exceptions, where I first learned of them in Smalltalk derive from a prototype class that isn't named Exception, and I've seen all manner of uses of the same machinery in stack-twisting. After all once you have full closures, and full control over your stack and context why shouldn't you use it for higher order abstractions involving the stack-context?

pygy_ 15y ago

Another valid and mysteriously killed post. When are the admins going to do something about this? ---- in [1], tomp [2] posted: That's one way to look at it, and it certainly is valid, to some extent. Another way to look at it is that exceptions are fundamentally limited, and conditions provide a whole new sea of possibilities. His example is rather awkward and actually confuses the reader, rather than excites. The point of conditions actually is to allow flexibility without all the if statements and delegates. His final getVal() function should look like this Object getVal() { try { if (val == null) throw new NoValException(); else return val; } catch (UseValRestart r) { return r.getVal(); } } and the high-level code should handle how the value is provided (either some specific value, user input, web request, random bits, etc...). So, one only has to write the code for getVal() once and can customize it indefinitely. ---- [1] http://news.ycombinator.com/item?id=2683678 http://news.ycombinator.com/item?id=2683678 [2] http://news.ycombinator.com/user?id=tomp http://news.ycombinator.com/user?id=tomp

Total_Meltdown 15y ago
I understand what the intent is, and I think it could be a useful mechanism, but as I've said in other posts, I disagree that exceptions are the way to go about it. I think something similar to exceptions, but intended for this kind of indirection would be good. But I'm strongly of the opinion that all exceptions should be treated as problems to be fixed, not just another pattern.