My heart bleeds
-
@Salamander said:
@Groaner said:
If you're worried about subsequent calls throwing (without catching them), why not do something like this:
You've changed the actual behaviour of the code so that it no longer propagates exceptions.
So clean up in the catch and then re-throw the exception. No big deal.
Note that this is only necessary because we've explicitly said that we're not going to use a class so that the compiler actually knows how to destroy it properly.
-
@Groaner said:
@Salamander said:
@Groaner said:
If you're worried about subsequent calls throwing (without catching them), why not do something like this:
You've changed the actual behaviour of the code so that it no longer propagates exceptions.
Fair point, but I would argue that it would be appropriate for the block where the exception is raised to be the block that handles it. I could see an argument for letting it bubble up to a caller five calls above, (i.e. generic exception logger, or generic message box, perhaps) but that doesn't seem as clean a separation of concerns. Would the caller be able to do anything meaningful to rectify the situation without access to variables that long went out of scope?
In the example Mason gave, I assume we're looking at some sort of database grid. What sort of exceptions might one expect to be raised from iterating through a recordset? ConnectionLostException? InvalidCursorException? GenericSQLException? (or whatever you want to call them). If your DB connection is dropped, the most graceful solution would be to try and reconnect (with limits on reconnection attempts, etc.), wouldn't it? That's likely going to necessitate refreshing the whole grid, as it would be assumed dirty and unreliable now that we're disconnected. If you kept the bookmark before the connection was dropped, you could possibly return to the same spot once the connection was reestablished (assuming the row wasn't deleted in the interim).
If, on the other hand, an exception is thrown because of invalid SQL used, there's not much one can do except log the error, or ask the user to send an error report. So the recovery method becomes different, and that's a good hint that there should be different ways to process different exceptions. If there's a common error reporting form, show it in catch blocks where it's relevant. If there are common pathways to recover from similar or different exceptions, call those in the catch block where applicable.
It doesn't matter what exception gets thrown. That's the whole point of try/finally, though: it's not exception handling; it's a deterministic state change regardless of whether an exception is thrown or not. This data-bound UI control example is just one scenario; I use the "set this state, do something, and then make sure to set it back afterwards" pattern all the time. It could be that a fatal error is thrown and what you're doing is useless. Or it could be that something gets thrown that your code anticipates (at a different level of the stack) and so you want to make sure your invariants are preserved. It could be that someone called Abort(), which raises an "invisible" exception (one that the debugger and the base-level exception handlers know to ignore) for the specific purpose of unwinding the stack without actually signaling an error to the user. The point is, your code doesn't know, and doesn't care, and doesn't need to. Just use try/finally and your invariants are preserved when the stack unwinds out of this block, no matter how it gets out.
-
@Groaner said:
Also, I seem to remember Alex having an opinion on relying on finally.
Yeah, that's about not being able to rely on it to preserve persistent invariants in the face of failure, the way ACID guarantees in a database do. I never suggested doing that. But for preserving program invariants in the face of failure, try/finally is an excellent tool.
-
@Groaner said:
Fair point, but I would argue that it would be appropriate for the block where the exception is raised to be the block that handles it. I could see an argument for letting it bubble up to a caller five calls above...
Letting exceptions propagate up the call stack is one of the primary features of exceptions.
-
@Mason Wheeler said:
@Groaner said:
Also, I seem to remember Alex having an opinion on relying on finally.
Yeah, that's about not being able to rely on it to preserve persistent invariants in the face of failure, the way ACID guarantees in a database do. I never suggested doing that. But for preserving program invariants in the face of failure, try/finally is an excellent tool.
Actually, Alex makes a mistake there, too, by assuming transactions are fool-proof. What if, immediately after the commit, the datacenter spontaneously bursts into flames and the transaction is lost?
Off-site, fully-synchronous backup? MIRVs.
And so-on.
-
@morbiuswilters said:
Actually, Alex makes a mistake there, too, by assuming transactions are fool-proof. What if, immediately after the commit, the datacenter spontaneously bursts into flames and the transaction is lost?
Yeah! What happens if crazy Uncle Vlad has a brain-fart and decides to nuke the whole of the western seaboard to glass? What happens to my database of rare newt pictures then? Huh? Huh?
-
@Groaner said:
Would the caller be able to do anything meaningful to rectify the situation without access to variables that long went out of scope?
The usual rule about exceptions is to catch them only at places where you can do something meaningful about rectifying the situation. Sometimes the only meaningful thing is to log the result and exit in a quivering heap (alas) but life's like that sometimes, but more often than not there's something that knows a better recovery strategy (e.g., “The file isn't there? We'll try another place. Or make a new one.”) and the exception works as a way to get the message to that point without having to clutter up everything in-between.C++ programmers are relatively late to the exception game; the language has had them for ages, but nobody would use them as their implementation was usually terrible. Other programming languages — many other programming languages — have had them and used them for a substantial amount of time now, so there's a lot of practical experience with patterns for using them well.
-
@dkf said:
@morbiuswilters said:
It skyrockets in value to Japanese perverts?Actually, Alex makes a mistake there, too, by assuming transactions are fool-proof. What if, immediately after the commit, the datacenter spontaneously bursts into flames and the transaction is lost?
Yeah! What happens if crazy Uncle Vlad has a brain-fart and decides to nuke the whole of the western seaboard to glass? What happens to my database of rare newt pictures then? Huh? Huh?
-
@dkf said:
What happens to my database of rare newt pictures then?
Are they common pictures of rare newts, or rare pictures of common newts?
-
@blakeyrat said:
@dkf said:
Common newts. Smoking hot pan. 15 seconds per side. Magnifico!What happens to my database of rare newt pictures then?
Are they common pictures of rare newts, or rare pictures of common newts?
-
@blakeyrat said:
@dkf said:
What happens to my database of rare newt pictures then?
Are they common pictures of rare newts, or rare pictures of common newts?
The thought that dkf would have a database of rare Newt pictures, and what Newt might have been doing in those pictures that would make them "rare" is disturbing. I hope that dkf's purpose in having such a database is benign, like blackmail, and not something more, um, personal...
-
@HardwareGeek said:
The thought that dkf would have a database of rare Newt pictures, and what Newt might have been doing in those pictures that would make them "rare" is disturbing. I hope that dkf's purpose in having such a database is benign, like blackmail, and not something more, um, personal...
Given that I'm not and never have been a US citizen, Gingrich pictures have little value to me. He's not my political slimeball.
-
@dkf said:
Given that I'm not and never have been a US citizen...
Wait, but you're in the UK, our 53rd state..
-
@dkf said:
Filed under: that picture makes him look fat and evil
He's also shorter than his pictures might suggest.
@morbiuswilters said:
Wait, but you're in the UK, our 53rd state..
Don't forget Israel. Or Japan. Or South Korea. Or... Poland.
-
@Groaner said:
@morbiuswilters said:
Wait, but you're in the UK, our 53rd state..
Don't forget Israel. Or Japan. Or South Korea. Or... Poland.
Those aren't states, you silly goose! Those are future sites of "Generalissimo Wilters' Memorial Toxic Waste Dumps".
-
@Groaner said:
He's also shorter than his pictures might suggest.
I was guessing, from his picture, that he was somewhere in the region of 8" to 12" tall. I got a ruler out to measure the picture on the screen and made a guess and all. That seems a bit large as newts go (which often seem to come out as about half that according to a very swift trawl of Wikipedia) but I don't really claim to be knowledgeable about newt sizes.
-
@dkf said:
@Groaner said:
He's also shorter than his pictures might suggest.
I was guessing, from his picture, that he was somewhere in the region of 8" to 12" tall. I got a ruler out to measure the picture on the screen and made a guess and all. That seems a bit large as newts go (which often seem to come out as about half that according to a very swift trawl of Wikipedia) but I don't really claim to be knowledgeable about newt sizes.Your suck at measuring. He's like, 2.5 inches tall.
-
@morbiuswilters said:
He's like, 2.5 inches tall.
I'm sorry you've got such a small screen.
-
@dkf said:
@morbiuswilters said:
He's like, 2.5 inches tall.
I'm sorry you've got such a small screen.That would have to do with pixel density, not size of the screen.
-
@morbiuswilters said:
@dkf said:
What's a good ppi these days? Six? Eight?@morbiuswilters said:
He's like, 2.5 inches tall.
I'm sorry you've got such a small screen.That would have to do with pixel density, not size of the screen.
-
@bstorer said:
@morbiuswilters said:
@dkf said:
What's a good ppi these days? Six? Eight?@morbiuswilters said:
He's like, 2.5 inches tall.
I'm sorry you've got such a small screen.That would have to do with pixel density, not size of the screen.
Apple has some new screens that are into the double digits, but it hurts my eyes to read text that small. Also, it'll cause my knee to act up, which usually means a storm is brewin' but if I'm using those Apple Movie House screens I won't know if I need to go out and put up my tarps so I can collect the rain in my barrels in case they take us off the gold standard again and we have to go back to conducting commerce with jugs of water like it were in the old days, back before.. you wouldn't remember..
-
@morbiuswilters said:
pixel density
What's their GPA? Maybe your pixels just need some extra private tuition.(It also depends on the scaling factor. One pixel in an image file no longer necessarily becomes one pixel on screen.)
