4 ms·

They do much more than just alter control flow - they add to the stack, and are used to debug issue or bonk out of your program entirely. In duck-typed like Rub

They do much more than just alter control flow - they add to the stack, and are used to debug issue or bonk out of your program entirely. In duck-typed like Ruby/Python, you don't necessarily know whether a piece of code is going to fail, so you assume it does. That's why you have try/catch blocks all over the place. In statically-typed languages like Java, you should be able to infer, mostly, what your program is doing at runtime, and if it's doing something you're expected, you raise an exception/error so that you stop processing whatever you're processing.

klodolph 9y ago
> In duck-typed like Ruby/Python, you don't necessarily know whether a piece of code is going to fail, so you assume it does. That's why you have try/catch blocks all over the place. That's an unreasonable viewpoint. Whether you understand what a piece of code does at runtime is down to the particulars of the code far more than it depends on the language you choose, and it's nothing but code smell to put try/catch everywhere because the code isn't doing what it's supposed to be doing. At best we might agree that it's difficult to maintain a high level of code quality in a large Python project, but try/catch everywhere won't improve things. There are generally two good places to put try/catch. The first is to put try/catch around a small piece of code that is expected to throw an exception, like parseInt(), and handle the exception right there. The second is to put try/catch around a piece of work which is large enough to make a decision about even when you don't know why it failed—things like top-level HTTP request handlers in web servers, or individual work items in batch processors where you can decide to skip the item and move on to the next. In either of these cases, you're using exceptions to alter control flow. That's the same way it works in Python, Java, C++, C#, and so many others. And Go uses the same principle, too, even though Go uses error returns. Which is why I am still confused about your original comment—since Go does not have exceptions. Go literally just has panic() and return.
paulddraper 9y ago
> In statically-typed languages like Java, you should be able to infer, mostly, what your program is doing at runtime Perhaps if your exceptions are type-checked. AFAIK Java is the only language that does that. I find that "Use exceptions, but don't use them for flow control" always comes from Java folks. Everyone else either doesn't use exceptions, or embraces them.
shusson 9y ago
> In duck-typed like Ruby/Python, you don't necessarily know whether a piece of code is going to fail, so you assume it does You should always assume there may be runtime errors regardless of whether you have some sort of static type safety or not. There are some languages that can guarantee no runtime errors, but they make significant sacrifices in terms of features [1]. [1] http://www.adacore.com/sparkpro/ http://www.adacore.com/sparkpro/

klodolph 9y ago

> In duck-typed like Ruby/Python, you don't necessarily know whether a piece of code is going to fail, so you assume it does. That's why you have try/catch blocks all over the place. That's an unreasonable viewpoint. Whether you understand what a piece of code does at runtime is down to the particulars of the code far more than it depends on the language you choose, and it's nothing but code smell to put try/catch everywhere because the code isn't doing what it's supposed to be doing. At best we might agree that it's difficult to maintain a high level of code quality in a large Python project, but try/catch everywhere won't improve things. There are generally two good places to put try/catch. The first is to put try/catch around a small piece of code that is expected to throw an exception, like parseInt(), and handle the exception right there. The second is to put try/catch around a piece of work which is large enough to make a decision about even when you don't know why it failed—things like top-level HTTP request handlers in web servers, or individual work items in batch processors where you can decide to skip the item and move on to the next. In either of these cases, you're using exceptions to alter control flow. That's the same way it works in Python, Java, C++, C#, and so many others. And Go uses the same principle, too, even though Go uses error returns. Which is why I am still confused about your original comment—since Go does not have exceptions. Go literally just has panic() and return.

paulddraper 9y ago

> In statically-typed languages like Java, you should be able to infer, mostly, what your program is doing at runtime Perhaps if your exceptions are type-checked. AFAIK Java is the only language that does that. I find that "Use exceptions, but don't use them for flow control" always comes from Java folks. Everyone else either doesn't use exceptions, or embraces them.

shusson 9y ago

> In duck-typed like Ruby/Python, you don't necessarily know whether a piece of code is going to fail, so you assume it does You should always assume there may be runtime errors regardless of whether you have some sort of static type safety or not. There are some languages that can guarantee no runtime errors, but they make significant sacrifices in terms of features [1]. [1] http://www.adacore.com/sparkpro/ http://www.adacore.com/sparkpro/