Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Databases Programming Software IT

Database Error Detection and Recovery 163

CowboyRobot writes "ACM Queue has an interview by Steve Bourne with Bruce Lindsay, responsible for a lot of the SQL and RDBMS we use today, in which they discuss error detection and recovery. My favorite part other than the photos is the definition of Heisenbugs - those problems that disappear only when you explicitly look for them."
This discussion has been archived. No new comments can be posted.

Database Error Detection and Recovery

Comments Filter:
  • I know it must be here somewhere... saw it here just a couple of seconds ago...

    Where is it?

    • Designing for failure may be the key to success.
      Engineering for Failure

      If you were looking for an expert in designing database management systems, you couldn't find many more qualified than IBM Fellow Bruce Lindsay. He has been involved in the architecture of RDBMS (relational database management systems) practically since before there were such systems. In 1978, fresh out of graduate school at the University of California at Berkeley with a Ph.D. in computer science, he joined IBM's San Jose Research Labo
    • I'm not sure, but it was moving at about 40m/second.
  • Rite of Passage (Score:5, Interesting)

    by beldraen ( 94534 ) <chad...montplaisir@@@gmail...com> on Saturday December 04, 2004 @12:27PM (#10996432)
    Heisenburg bugs are a rite of passage in the computer world. They result from the production environment being different from the development environment. For instance, a debugger may initialize all memory in the process space to zero. An errant loop control now happens to be set properly, so no error occurs; however, in the production environment, whatever is left over in memory is used, which means the loop wanders off into nomansland and crashes. Always initialize your variables, period! Even in languages that automatically do it for you so that you are aware to what they are initialized.
    • Re:Rite of Passage (Score:2, Interesting)

      by quamaretto ( 666270 )

      I have been dealing recently with a Heisenbug in Internet Explorer while trying to design a web page with floats. (Wed designers, weep with me.) The trouble is that a certain page renders wrong (what I think is wrong), the first time you look at it after opening Internet Explorer, and then displays correctly every time you look at it afterward, even with 'refresh'.

      And yes, I really do have to design it for Internet Explorer.

      Also, early on in the development of the page, I was encountering a similar situat

      • Re:Rite of Passage (Score:1, Informative)

        by Anonymous Coward

        The trouble is that a certain page renders wrong (what I think is wrong), the first time you look at it after opening Internet Explorer, and then displays correctly every time you look at it afterward, even with 'refresh'.

        That sounds like one of these bugs [positioniseverything.net]. I've had even worse - all the text on the page disappearing, but minimising and then maximising the window fixes it! Internet Explorer really is a piece of shit.

        • Thank you, bookmarked. (Register! plzkthx)
        • That's as bad as that browser rendering bug that shows up on slashdot all the time. Most of the text except for the left bar disappears, but shrinking and then increasing the text size fixes it! The browser that displays that bug really is a piece of shit.

          (Note: I don't actually think Firefox is a piece of shit)

      • my least favourite in internet explorer is that if you have a site that is delivered chunked via mod_gzip and press refresh IE decides that you only wanted the last chunk !

    • Re:Rite of Passage (Score:3, Interesting)

      by thepoch ( 698396 )
      This probably resulted in the quote: "If you can't repeat it, it's not a bug" End-User : Look at this bug! Developer: What bug? End-User : This bug! Developer: Oh? Try it out on my development computer. End-User : Developer: See, it's not a bug. Must be your Windows or something. Have your IT department support it. Manager : All right, no bugs, pay up. If only development was like this little play I wrote.
    • Don't forget the unintentional stack smashing, which is all too easy to do when you're writing tricky pointer code in C, and damned hard to find, especially when you barely understand the code you just wrote in the first place.
      • Re:Rite of Passage (Score:5, Informative)

        by Jeremi ( 14640 ) on Saturday December 04, 2004 @01:44PM (#10996752) Homepage
        Don't forget the unintentional stack smashing, which is all too easy to do when you're writing tricky pointer code in C, and damned hard to find, especially when you barely understand the code you just wrote in the first place.


        For stuff like this, a wonderful debugging tool is valgrind [kde.org] -- it takes about 5 minutes to download and install (GPL, Linux/x86), and will find all kinds of memory-usage bugs in your program that you never even knew existed.

      • when you barely understand the code you just wrote in the first place.

        Debugging code is harder than writing code. If you write the most complex code you are capable of, you are by definition not smart enough to debug it. :)

        -
        • you could at least attribute it :

          Debugging is twice as hard as writing the code in the first place. Therefore,if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

          -- Brian W. Kernighan

          more here [dotgeek.org]

          • Attributing a quote is twice as hard as (mis-)quoting it in the first place. Therefore, if you write the witty quotes as cleverly as possible, you are, by definition, not smart enough to attribute it.

            -
    • Re:Rite of Passage (Score:3, Interesting)

      by leoval ( 827218 )
      Nothing like putting extra printf's to get rid of an error. Thankfully the universe is a better place since the invention of Purify, (since most of the Heisenbugs are memory problems --evil pointers--). However the most challenging heisenbugs are the timing related ones, specially in networked applications. Those @#%'s are really hard to debug.I remember a project in particular where the heisenbug will only occur in Windows (not flame intended), but it would go away whenever we put a fprintf just before se
      • Re:Rite of Passage (Score:4, Interesting)

        by mikael ( 484 ) on Saturday December 04, 2004 @03:00PM (#10997140)
        Oh man, I remember those. The worst case was when I was trying to fix a SLIP (the model protocol) bug in an Ethernet probe. You could step through the code and everything worked correctly. The Token Ring network version worked correctly without failing. But run the system normally, and it failed to connect. The quickest solution was to compare the two code segments of each system; the only difference. was a 15 millisecond wait. Once replaced the system worked correctly (This was a requirement specified in the back page appendix of the modem chip specification).
      • Re:Rite of Passage (Score:2, Interesting)

        by bsgenerator ( 725496 )
        I once worked at company on a program in qbasic. The small procedure I was working on was ok when used in a test-program, but when it was used in the 'real' program it barfed. After I looked for hours for non-existing bugs in only 10 lines of code, questioning my own sanity in the proces, I asked for help. It turned out to be the compiler we run afterwards who messed up, and was 'corrected' by a dummy if-statement at the right place.

        if (1=0)
        print("The end of the world...");

        Of course, another senior pro
        • Re:Rite of Passage (Score:2, Insightful)

          by Anonymous Coward
          Of course, another senior programmer saw the statemnent and removed it just before it was shipped to the customer...

          As well he should have. If you need something like that to stay, you need a comment explaining its purpose. "The following statement is never executed but necessary to work around a compiler bug" would be helpful. You could even describe the bug so they could check if it's still necessary once the next version of the compiler is released.

          • A senior programmer should know that very little justifies a useless change just before one ships. Removing dead code -- especially suspicious looking dead code -- does not help a project in any appreciable way. So shame on the junior programmer for not putting in a comment, and shame on the senior programmer for taking the bait.

            The proper endgame mindset should be, "Does this change (or more generally, this action) help me ship the product? If not, I won't do it."
    • Always initialize your variables, period! Even in languages that automatically do it for you so that you are aware to what they are initialized.

      So for example, perl initializes variables to 'undef' by default. I am already aware of this without setting the value explicitly. How do you justify setting the value to undef explicitly?
  • ignore this response.
  • Heisenbugs (Score:5, Funny)

    by base_chakra ( 230686 ) * on Saturday December 04, 2004 @12:31PM (#10996445)
    "Heisenbug as originally defined--and I was there when it happened--are bugs in which clearly the behavior of the system is incorrect, and when you try to look to see why it's incorrect, the problem goes away.

    This is a really cool article, but it was especially fun to see the heisenbug [jargon.net] mention. Years ago, some fellow CS people and myself conjectured a similar phenomenon that seemed to manifest once in a while, in which a computer malfunction goes away after one "proves" that there's no cause for the error to exist.

    Here's a list of heisenbug anecdotes [c2.com], but note that some of these submissions aren't strictly heisenbugs.
    • by JaredOfEuropa ( 526365 ) on Saturday December 04, 2004 @12:54PM (#10996549) Journal
      I remember compaints about a Windows NT server slowing down to a crawl even when there weren't that many people using it. So the SysOp would fire up a few performance monitors and keep an eye on the thing. Sure enough: no slowdowns, no performance issues, normal operation. But every time when the guy would leave, the system would slow down again after 5 minutes or so. For a few days this had us stumped.

      Then someone figured out that the system had the 'pipes' screensaver on that came with NT3.51. Of course, as soon as we started to diagnose the machine, the screensaver would disappear. And yes... the screensaver turned out to be the culprit, sucking all the system resources away. We removed it and all was well.

      Does anyone know who coined the term 'heisenbug' by the way?
      • Re:Heisenbugs (Score:1, Informative)

        by Anonymous Coward
        Fome Heisenberg's Uncertainty Principle ?
      • This problem also occurred with NT 4.0. The safe way of locking the console was to use either "blank" or "logon" as the screen saver. Even the stupid "Marquee" could suck up half the CPU.
      • Oh, man. Any screensaver other than "blank screen" on a production machine is a mark of a fucking idiot admin. I saw that problem too many freaking times to count. I also got "but I like that screensaver" in reply too many times. Fucking NT admins.
        • >Fucking NT admins.

          Yeah, like Linux admins are all Einsteins.

          It's even worse that on Windows - while screensaver on Windows had to be liked by a particularly stupid admin in order to be enabled, on Linux it was enabled by the manufacturer - how fucking stupid is that?

          As recently as Red Hat 8.0, they had screensaver activated by default, and it was known to cause system freeze-ups. Not to mention that X-Windows shouldn't have been installed by default anyway.

          It's inexcusable to be stupid, but how stup
          • Who the hell said anything about linux???
            • Doesn't "NT admins" mean Windows server administrators?

              My point is that a stupid admin is a stupid admin and will always be a stupid admin no matter what OS he or she uses.
              I know some stupid admins who used to be stupid NT admins and their company has switched to Linux lately. They're now stupid Linux admins. Same people. There's no need to single out Windows users.
      • A 3D screensaver on a server? Now that's the sort of innovative shit that Linux needs to succeed in the marketplace ;)

        (Yes, I know about Xscreensaver [jwz.org])

      • There's this lady I used to work for who is a naturopathic doctor. I used to fix her computers. Everything would work fine as soon as I got there, everything would work fine while I was there, and then suddenly not more than an hour or two after I left, things would cease working. It has always kind of bothered me. I'm glad I have a real job now, and I don't have to worry about those possessed computers.
    • Years ago, some fellow CS people and myself conjectured a similar phenomenon that seemed to manifest once in a while, in which a computer malfunction goes away after one "proves" that there's no cause for the error to exist.

      I think what you're describing is a corollary to the well-known fact that when the support person is investigating the problem it never manifests again until after they're gone.

      Proving there is no cause for the error is like all of the passengers believing the plane will fly (the real

    • This is an example the Schroedinbug, a bug defined as one that doesn't exist until someone reads the code and proves that it can't run, and then everyone's system crashes, even though they were all running fine until then.

      Some programs die, but some programs live, I guess.

      KFG
  • by Anonymous Coward on Saturday December 04, 2004 @12:33PM (#10996453)
    BL: In the heart monitor case, you better keep the heart going, whereas in the Microsoft Word case, you can just give them a blue screen and everybody is used to that.

    SB: But also in the heart monitor case, it?s hard to ask users if they want to keep the heart going because the answer is pretty obvious, whereas in the Word case, you can ask the user in some cases what to do about it.


    New Microsoft Pace - Heart Monitor and Pacemaker

    STOP: 0x0000000A (0x0000015a, 0x0000001c, 0x00000000, 0x80116bf4)
    IRQL_NOT_LESS_OR_EQUAL - Beat.exe
    Please hold your breath while a dump file is created...

    • New Microsoft Pace - Heart Monitor and Pacemaker....Please hold your breath while a dump file is created...

      Technology where the screen and the user become the same color. Now that's bonding.
    • True story - I went in for an X-ray a few years back, and the tech was fiddling around with a computer. I was shocked to see she was using Windows 3.1 to run a Visual Basic applicaion that controlled the X-ray machine. As I watched, she got several errors from the program, which she clicked through. "Oh, it always does that," she said when I expressed my...er...dismay. This was back when there wasn't much you could do to a Windows box other than WINNUKE.EXE...these days you can take the whole box hostag
  • Picture (Score:5, Funny)

    by bonzoesc ( 155812 ) on Saturday December 04, 2004 @12:34PM (#10996456) Homepage
    That picture is really something. I didn't know Gandalf wrote bsh.
    • Comment removed based on user account deletion
    • That picture is really something. I didn't know Gandalf wrote bsh.

      That's what it looks like when the beard/pipe/suspenders crowd groom themselves. Sort of like an aged flower child version of Bill Gaines [allaboutcomix.com] a la R. Crumb.
    • If Gandalf wrote it ...
      ... wouldn't it be gsh rather than bsh
    • Re:Picture (Score:3, Informative)

      by SnowZero ( 92219 )
      The picture is Lindsay, not Bourne. See here [ibm.com] for an earlier picture. I admit its a bit disturbing, but some CS people don't want to "waste" time shaving and getting their hair cut. I also need a haircut and a shave, but not nearly as bad as him. This picture has helped motivate me :)
      • Oh dis!


        That reminds me, I'm only a week or so from a mullet. And I can't have that happen, I don't want people thinking I'm McGyver with glasses.

  • by Anonymous Coward
    I have worked on electronic hardware for forty years. Over that period, I have experienced many such bugs. You carefully trace the problem and get to the point where you say: "It must be this!" So you go there and the signal is correct but now the equipment works properly. It stays working properly. I'm used to problems that are sometimes there and sometimes aren't; this is different. The working condition stays.

    It's like the equipment is playing hide and seek with you. You found the problem and the
    • The only thing more frustrating than trying to figure out why something doesn't work when it should -- is trying to figure out why something works when it shouldn't.
      • I think its funny that both problems are easily solvable simply by throwing enough momey at them. Alas, the world makes some sort of sick sense.
  • by Anonymous Coward on Saturday December 04, 2004 @12:40PM (#10996486)

    A good design principle is: either do what you're told to do or tell us you didn't do it and why, but don't do something completely different.

    Exactly. Compare and contrast with MySQL's behaviour [sql-info.de].

    • NULL inserted into a NOT NULL column silently alters the data to fit.
    • VARCHAR values have trailing whitespace silently removed without asking.
    • Dividing by zero is not an error.
    • Inserting a value into a column that violates its constraints doesn't result in an error; MySQL guesses at the "correct" value instead. For example, limiting an integer column to 4 digits, and attempting to insert 99999 will result in 9999 being inserted without any error.
    • If MySQL finds that it can't create certain table types, it simply ignores referential integrity.

    That's why there are loads of people who point out that you can't trust MySQL for important data, or that it isn't a "real" database. A real database tells you when it fails, which is something that is necessary for trusting it with data integrity.

    The key point here is that if you go to sea with only one clock, you can't tell whether it's telling you the right time.

    Ahh... but a man with one clock always knows the time - but a man with two is never quite sure :).

    • by Anonymous Coward
      A man with two clocks that agree has a much higher degree of certainty.
      • by Anonymous Coward

        Of course, both clocks could be totally broken but have been set to the same (unchanging) time by obsessive/compulsive someone "tidying up". Then the clocks are each right twice a day but not when you think.

    • by Anonymous Coward
      And when the two meet, they go looking for a third guy who has a clock so they can settle the argument. And then they all go looking for another guy since none of them agree.

      All data is imperfect without proper reference, and all reference data is external. See the art of calibration.

      Even a room full of atomic clocks will not reflect the correct time in 100 years because the earth-sun system isn't slave to the rhythms of any process other than it (at least in any quantifiable sense). They could be several
    • Welcome to the obligatory MySQL flame that must be attached to all database-related postings.

      Any second now, the parent is going to be modded down, right? Everything noted in the parent is well documented functionality in MySQL, which takes the approach of not generating application-breaking exceptions, and allowing you to split of data validation as either a pre-processing step or a more macroscopic endevor.

      You may not like this approach. If you don't, then don't use MySQL. There are lots of other (very
      • by Anonymous Coward on Saturday December 04, 2004 @02:14PM (#10996911)

        Everything noted in the parent is well documented functionality in MySQL

        Well documented, perhaps, but nevertheless utterly wrong and often in violation of the SQL specifications.

        Slashdot doesn't need your redundant and off-topic flames.

        Try reading the article. I was pointing out that MySQL's behaviour goes 100% in opposition to what the article calls a "good design principle". How on earth is that off-topic?

      • by Anonymous Coward
        > split of data validation as either a pre-processing step or a more macroscopic endevor.

        You're right that pre-processing is a good way to do constraints. We gave-up on using Oracle contraints, because they aren't very featureful. Well, that's not Oracle's fault. It's the fault of the SQL-standard. You can do *much* better error checking with a turing-complete programming language than you can with SQL. That's what we do with our applications even though we use Oracle. The biggest problem is that
        • by Anonymous Coward

          It's funny how that idiot isn't smart enough to argue the philosophical differences

          Before calling me and everybody who agrees with me names, go back and read what I posted. Most of it's a case of asking MySQL to do something, MySQL being unable to do it, and instead of throwing an error, doing something completely different.

          Whether you prefer your data integrity checks in your database or in your application is irrelevent to the point I was making. The person claiming that MySQL's trying not to gen

        • You can do *much* better error checking with a turing-complete programming language than you can with SQL. That's what we do with our applications even though we use Oracle. The biggest problem is that you must have good programmers.

          Which you obviously don't...

          You're right that pre-processing is a good way to do constraints.

          If your database has one user.
      • verything noted in the parent is well documented functionality in MySQL, which takes the approach of not generating application-breaking exceptions, and allowing you to split [off] data validation as either a pre-processing step or a more macroscopic endevor.

        It would be nice if such option was a system setting (or database-scope setting) somewhere. However, I rarely see apps where truncating numbers to fit is considered a good thing. COBOL does that and it has been the source of many bad bugs, such as w
      • > Everything noted in the parent is well documented functionality in MySQL, which takes the approach of
        > not generating application-breaking exceptions, and allowing you to split of data validation as
        > either a pre-processing step or a more macroscopic endevor.

        Failing to provide exceptions to obvious errors is now 'well documented functionality'? Really? Exactly where? I remember when MySQL listed most of these issues as 'known problems'.

        I think you're just misinterpreting the cause of these e
    • This article is about databases, why are you talking about MySQL... stay on topic please.
    • MySQL will always ignite slashdot flamewars because there is always a Postgres troll standing by to start one.
  • Comment removed based on user account deletion
  • by Anonymous Coward on Saturday December 04, 2004 @12:45PM (#10996511)
    The guy looks like he's covered in coke dust.
  • Are Heisenbugs anything like the slashdot memory relapse? You know you've been reading too much /. when you say to yourself, "Wait, I think I saw that in /. somewhere." Then goto slashdot search to try to find it. You end up pulling 20000 articles -- like finding a needle in a haystack.

    Perhaps /. needs better database tools.

    • by Anonymous Coward
      And /. needs better thread handling too. When there's to much posts, the thread is splited in 72 pages. Pages 1, 2, and 3 are the same post reappearing over and over, then page 4 skipped a couple messages. You have to manually change the startat= parameter in the URL to see thoses missing posts. This is nuts. I mean, how difficult is it to code message threading? It's not rocket science. This makes /. look like ass when they are complaining about Microsoft bugs.
  • Heisenpages (Score:2, Funny)

    by Anonymous Coward
    Web pages that disappear when you try to look at them....
  • by martyb ( 196687 ) on Saturday December 04, 2004 @01:04PM (#10996584)

    One of the things that is addressed to some extent in the article is the need to make error messages meaningful! There is nothing more frustrating to me than to encounter an error message like "syntax error."

    At a minimum, an error message should have a Unique ID of where in the code this message is coming from, what was expected, what was actually found, and the context where it was found.

    EXAMPLE:

    for (i=1;i<=10;i++) {printf "%d\n', i}
    Which would you prefer:
    1. Syntax error in line 1.
    2. ERROR [ID=WXY1234] found "'" where expected """ in statement: "{printf "%d\n', i}" on line: 1.

    In my experience, meaningful error messages save more debugging time than it takes to put them in.

    • by Anonymous Coward
      Damn, if only you worked for Microsoft. This is a major reason I absolutely hate diagnosing any problem on a Microsoft system. "Unable to connect to server." What the hell does that mean? A DNS failure? Connection timed out? Connection refused? No route?
      • by Anonymous Coward
        This mean you have reboot Windows and the problem will magically solves itself.
      • God, Microsoft Frontpage client is my favorite. Error messages like "Could not find a web server at 'your.host.name' on port 80. Please check to make sure that the web server name is valid and your proxy settings are set correctly. If you are sure that everything is correct, the web server may be temporarily out of service." Long, verbose, completely useless. "Could not find"? Why? "Out of service?" WTF?
    • by Anonymous Coward on Saturday December 04, 2004 @02:19PM (#10996942)
      I agree with your sentiment, but I think that this particular example can be used to describe why error messages are exactly the way they are. The compiler has no way of knowing that you DIDN'T want a single quote, comma, space, letter i, and closed curly brace to be part of your string literal -- they're all valid characters for inside a string literal, after all. It has no idea that you typed a single quote in error instead of a double quote -- Maybe you want the output to look like:
      1
      ',i}2
      ',i}3
      ...
      and your only mistake was forgetting a final ",i); It is only when it gets to something that is clearly wrong (like the NEXT double quote in the file, which is followed by something that doesn't look like the proper token -- or maybe the end of the file itself) that it knows something was wrong. It would take a lot of guessing to scan through the mess that looks like a string literal and arbitrarily decide that it must have been the single quote (also used as an apostrophe) where you went wrong. I think the best thing it could have told you was that it found an error immediately after parsing the string literal that starts on line 1, show you the line, and point to the character that starts the literal. Anything beyond that is mere speculation.

      I hand crafted a (simple) C compiler when an undergrad, and figuring out where the stream of good tokens turns to mush is very hard. Often by the time you realize there's a problem, you already missed the real problem.

      I agree you should be as explicit and precise as you can in telling the user, but there are so many ways to screw things up, and they look so much like unusual-but-legal syntax that it's probably better to tell the user / developer what you actually do know, rather than guess about what might have been wrong.

      Now, on the other hand, if your statement was

      int y = ;
      the compiler should probably be able to tell that the equals operator needs an operand of some kind on the right, and there was none. It ought to tell you immediately that the problem was a missing right hand operand for the equals operator, and it should be able to tell you the exact position of the equals that is missing the operand. Just spitting out "syntax error" in a case like that is a little weak.
    • No, I'd rather have just "syntax error". Because when compilers attempt to be more detailed than that, they almost always produce details that are wrong. It's just the way parsers work; they can tell you something's wrong, but they can't tell *what* is wrong. In your example, the actual error would be "newline not allowed in string constant", because it has no way of knowing that ' was supposed to be a ".
    • by Anonymous Coward
      Which would you prefer
      1. Syntax error in line 1.
      2. ERROR [ID=WXY1234] found "'" where expected """ in statement: "{printf "%d\n', i}" on line: 1.


      I would prefer an error message indicating the real source of the problem, an unterminated string literal. What you list as the 2nd option doesn't describe the problem that the compiler runs into when trying to compile that code.

      I submit to you option #3:

      3. ERROR [ID=123123] Unterminated string literal in line 1
    • In the programming environment I use, the close brace is highlighted in bright pink to indicate that something's probably wrong. Also, the ", i}" is in blue to indicate that it is still part of a string constant. If I actually try to compile the code despite the editor telling me exactly what the compiler will think of the code, I get 'temp.c:6:38: missing terminating " character', which is quite explanitory and is undoubtedly true (unlike your message; I often put single quotes around things inside double-
  • Some languages do have support for error detection, for example the express data modelling language (and express-c its executable counterpart). http://www.ap210.org/tiki/tiki-index.php?page=EXPR ESS has some information on express for anyone interested. Basically, it lets you specify integrity constrains on the model it defines.
  • Heisenbugs.

    Are there Heisen-features as well?

  • Exception Handling (Score:3, Interesting)

    by Joe U ( 443617 ) * on Saturday December 04, 2004 @01:27PM (#10996661) Homepage Journal
    Not quite on topic, but, I once tried writing code in SQL (in this case for ColdFusion) by using stored procedures and exception handling.

    What a nightmare.

    Many people code unique inserts like this.

    Check for duplicate record.
    if not found, then insert.
    else, prompt user.

    Using exception handling, you code like this.

    insert.
    if error thrown, prompt user.

    One less query, lots less code.

    One problem, the web application language treated all db errors as fatal. When asked, I was told this was by design.

    Thinking about it, I feel that Macromedia didn't want me to code efficiently. You don't sell extra ColdFusion servers if you can offload all your data logic to the SQL server. (Where it belongs)
    • in this case for ColdFusion....One problem, the web application language treated all db errors as fatal. When asked, I was told this was by design.

      I don't think that is the case. ColdFusion can capture DB errors. For example, it has a statement something like <cfCatch errorType="database">....

      Whether it always works or not is perhaps another matter.
      • It would, but that's not what I wanted. All errors were fatal, including informative errors, it made EH inside the procedures impossible.

        A simple example.

        Insert record
        If duplicate record error then update record instead
        if other error throw exception

        Now, a duplicate record would throw a fatal error to coldfusion. I could then catch that error in CF, but now I have to code for 2 possible outcomes, a fatal error that isn't fatal, and a fatal error that is fatal. At that point, you might as well split it int
    • "Many people code unique inserts like this.

      Check for duplicate record.
      if not found, then insert.
      else, prompt user."

      There's a race condition in this- a window between the checks and the insert.

      So you could get an error anyway- a DB error if there's a unique constraint, data corruption if there isn't.

      What you could do is lock (prevent other checks and inserts) then check, then insert if would be unique. But the lock could signifcantly affect performance - depends on the locking and the database.

      As you sa
  • pack
    reindex

    restore backup.....

    repeat

  • So this Heisenburg guy is to blame for the errors. So...does he work for Microsoft or something?
  • by chaves ( 824310 ) on Saturday December 04, 2004 @01:37PM (#10996699)
    "That's one of the real problems in today's programming language architecture for exception handling. Each component should list the exceptions that were"That's one of the real problems in today's programming language architecture for exception handling. Each component should list the exceptions that were raised: typically if I call you and you say that you can raise A, B, and C, but you can call Joe who can raise D, E, and F, and you ignore D, E, and F, then I'm suddenly faced with D, E, and F at my level and there's nothing in your interface that said D, E, and F errors were things you caused. That seems to be ubiquitous in the programming and the language facilities. You are never required to say these are all the errors that might escape from a call to me. And that's because you're allowed to ignore errors."

    I bet he didn't look into Java. Java (at least) allows and enforces that. A method will only throw an exception if declares to do so. A caller is forced to provide appropriate handlers or to declare it throws the exceptions not handled at its level. If a method can throw A, B or C but gets D during its execution, it has to in some way map D to either A, B or C (or not throw an exception at all).

    Of course, I am talking here about checked exceptions. Unchecked exceptions are supposed to represent *bugs*, and nobody should be trying to capture those.

    The sad thing is that even seasoned Java programmers do not understand how to write code w.r.t. exception handling. And beginners are usually turned off by the verbosity required by exception handling, so it is usual to see code where people capture (because they are forced by the language) and ignore exceptions (because they are too lazy and/or stupid to understand the consequences).

    • by koreth ( 409849 ) on Saturday December 04, 2004 @03:00PM (#10997142)
      it is usual to see code where people capture (because they are forced by the language) and ignore exceptions (because they are too lazy and/or stupid to understand the consequences).
      Ignoring exceptions completely is almost always a bad idea (though what do you do to handle, say, the InterruptedException that can be thrown by Thread.sleep(), or a CloneNotSupportedException from one of your own classes that you know is cloneable?) But there is some legitimate difference of opinion [mindview.net] about whether Java's checked exceptions were a good idea or not.

      In my Java code I'm pretty paranoid about catching exceptions and handling them in as intelligent a way as I can, and even so I've run into plenty of situations where there's really no good way to recover from an underlying error and I end up just repackaging the exception into a higher-semantic-level one and tossing it upstream, where the upstream code does the same thing, all the way back out to the UI code, which displays an error message. At which point all I've achieved is cluttering up the intermediate layers of code with useless exception handlers when I could have gotten exactly the same effect by just catching a superclass exception in the UI code and displaying the same error message. (In addition to catching any specific exceptions that would cause a different result, of course.)

      Most likely anyone who's written a Java app of any appreciable size has run into exactly the same thing. In theory, and in small sample snippets of code, checked exceptions seem great. In practice, even some experienced Java gurus find them more hassle than they're worth. I'm quite certain that over the years I've spent far more time writing code to handle checked exceptions than they've saved me in debugging or diagnosis time. That to me is not the sign of a helpful language feature.

      • Ignoring exceptions completely is almost always a bad idea (though what do you do to handle, say, the InterruptedException that can be thrown by Thread.sleep(), or a CloneNotSupportedException from one of your own classes that you know is cloneable?)

        When a seemingly-impossible thing happens, I wrap it in a RuntimeException. Something like this:

        File f = blah;
        try {
        ....InputSource src = new InputSource(f.toURL().toString());
        } catch (MalformedURLException e) {
        ....throw new RuntimeException("java.io.

    • That's just what I thought:
      try {
      ...
      } catch (Exception e) { e.printStackTrace(); }

      or WORSE:
      try {
      ...
      } catch (Exception e) { }

      But it's a good mechanism, and just bad programmer practice.
  • Cool! (Score:2, Funny)

    by Anonymous Coward
    I just found my new avatar picture. :)

    ps: not a troll, this guy's a freakin genius. I hope I look like that in 20+ years.
    • Take off the glasses, give him a wizard's staff and he's ready for a 3 way battle with Gandalf and Saruman.
  • maybe they need some comensators [memory-alpha.org]

  • SB It's certainly true that one of the mind-sets you have to have when you're writing code and designing systems is: What's going to break? There's a broad range of possibilities for approaching this, depending on the type of application or software. If you're writing a Microsoft Word-type program, the way you approach this might be different from if you're designing a heart monitor.

    BL In the heart monitor case, you better keep the heart going, whereas in the Microsoft Word case, you can just give them a
  • In the heart monitor case, you better keep the heart going, whereas in the Microsoft Word case, you can just give them a blue screen and everybody is used to that.

    But blue screens probably cause a lot of stress heart-attacks, so that the end result is the same.
  • by sapgau ( 413511 ) on Saturday December 04, 2004 @03:27PM (#10997265) Journal
    I couldn't help noticing Mr. Lindsay explanations of what a process would or could do. He kept describing it in the first person:

    - "You asked me to do X, I didn't do it."
    - "Aha, this seems like I should go further."
    - "Oh, I see this as one of those really bad ones."
    - "I'm going to initiate the massive dumping now."

    Obviously he is an expert in his field but I'm not sure if he talks this way because of his personality or because there isn't a vocabulary big enough to describe it.

    Would you imagine a medical doctor talking this way?

    - "So the white blood cells fight with the cancer cells: die evil cell, die!!"

    Or an engineer:

    - "The little peg ask it's big brother : can you help me convert this energy into circular motion?"
    • by zuzulo ( 136299 ) on Saturday December 04, 2004 @05:17PM (#10997861) Homepage
      Strangely, this is a phenomenon i have noticed with experts in many different fields who *really* understand what they are doing. They really do have an internal model of what is happening that essentially boils down to this sort of simplicity.

      In fact, the correlation is so strong that I am suspicious of folks who *cannot* boil an arbitrarily complex interaction into an easily understood metaphor.

      Jargon does in no way denote true understanding.
      • I've talked about some unrelated stuff with some friends once and we came to the conclusion that when you observe something, you compare it to yourself.

        Applying that idea to coding, it would mean that talking like that in relation to code (.. so I will ask the other component ..) would be like understanding and agreeing with what the code is doing. Talking about the code in other ways (.. so it will ask the user ..) may mean that you don't understand it (so you should observe it more as to understand it b
  • A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years.

    The on-line hacker Jargon File, version 4.1.0

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...