... In practice, though...
-
Some code I read today:
try {
// ...snip (dozens and dozens of lines doing something)...
} catch (e) {
// in theory, this point can never be reached.
}I felt weird when I noticed that what annoys me about this is not the fact that the exception is bound to happen and that it's going to fail silently (just to break something else down the stack) because of the rather catch - but rather the fact that the comment says 'theory' but that's actually an hypothesis.
-
@Renan said:
Some code I read today:
try {
// ...snip (dozens and dozens of lines doing something)...
} catch (e) {
// in theory, this point can never be reached.
}I felt weird when I noticed that what annoys me about this is not the fact that the exception is bound to happen and that it's going to fail silently (just to break something else down the stack) because of the rather catch - but rather the fact that the comment says 'theory' but that's actually an hypothesis.
Argh, yes. When I've seen stuff like this in the past I've simply add a line something like:
logger.error("In theory, this point can never be reached.", e);
... and quietly checked it back in again with the rest of my changes.
Yeah, yeah, always of course assuming that there is a log4j logger lying around somewhere in the class.
-
I find it interesting that we ARE sure enough it won't be reached to go ahead and skip handling or logging the error, but NOT sure enough to just leave out the try-catch altogether.
I feel like that's some negative middle ground.
Like, I can't decide whether to turn left or right at the end of the street, so I'll just drive into the ocean.
-
Could be a cocky Java developer... "this function says it throws some sort of exception, so I have to catch it - but I know better, there's no way that function could throw anything due to my 1337 preconditions checking!"
-
@ekolis said:
Could be a cocky Java developer... "this function says it throws some sort of exception, so I have to catch it - but I know better, there's no way that function could throw anything due to my 1337 preconditions checking!"
I should've said in the first post, this is in Javascript. So you aren't forced to catch anywhere. More like insecurity as superjer said.
-
@Matt Westwood said:
Yeah, yeah, always of course assuming that there is a log4j logger lying around somewhere in the class.
I do the same. Only, if no log4j logger happens to by lying around, then I usually add one myself.
-
@superjer said:
Like, I can't decide whether to turn left or right at the end of the street, so I'll just drive into the ocean.Rather like your navigation system not being able to decide
-
@superjer said:
I find it interesting that we ARE sure enough it won't be reached to go ahead and skip handling or logging the error, but NOT sure enough to just leave out the try-catch altogether.
I feel like that's some negative middle ground.
Like, I can't decide whether to turn left or right at the end of the street, so I'll just drive into the ocean.
There are some valid use-cases for this pattern, at least in java.
Specifically, when checked exceptions meet the Decorator pattern, pointless things like this are often the result.
Suppose you have an interface Foo with a method that can throw the checked exception Bar. Your actual implementing class FooImpl, however, never throws Bar - in fact, it even has it removed from the throws clause, which is legal in java.
Sadly, though, you're not directly working with FooImpl, but with FooDecorator, a decorator that can wrap arbitrary instances of Foo and itself implements Foo, too. That decorator has no idea if its inner Foo instance throws Bar or not, so it has to declare Bar in its throws clause - and you somehow have to catch it, even though FooImpl couldn't even throw it if it wanted to.
If you prefer practice instead of theory (u c my great pun?), replace Foo with InputStream, FooImpl with ByteArrayInputStream and Bar with IOException.
-
It's sensible in Javascript too, as you may have several scripts doing unrelated things on the same page. So if your slideshow script throws an error of any sort (usually due to someone using a broke-ass old browser), you don't want it to break your drop-down menus or your fancy drag-n-drop widget.
-
@PSWorx said:
@superjer said:
I find it interesting that we ARE sure enough it won't be reached to go ahead and skip handling or logging the error, but NOT sure enough to just leave out the try-catch altogether.
I feel like that's some negative middle ground.
Like, I can't decide whether to turn left or right at the end of the street, so I'll just drive into the ocean.
There are some valid use-cases for this pattern, at least in java.
Specifically, when checked exceptions meet the Decorator pattern, pointless things like this are often the result.
Suppose you have an interface Foo with a method that can throw the checked exception Bar. Your actual implementing class FooImpl, however, never throws Bar - in fact, it even has it removed from the throws clause, which is legal in java.
Sadly, though, you're not directly working with FooImpl, but with FooDecorator, a decorator that can wrap arbitrary instances of Foo and itself implements Foo, too. That decorator has no idea if its inner Foo instance throws Bar or not, so it has to declare Bar in its throws clause - and you somehow have to catch it, even though FooImpl couldn't even throw it if it wanted to.
If you prefer practice instead of theory (u c my great pun?), replace Foo with InputStream, FooImpl with ByteArrayInputStream and Bar with IOException.+1
