-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darren New wrote: > If you can't trust that your introspection keeps working when your > language says it should, then what do you trust? You're basically > arguing that since there can always be some sort of failure, you > shouldn't code to handle the errors you can.
That isn't what I'm saying. I'm saying that you should be conservative with what you trust to still be valid and correct. Why trust the current process' address space when you don't have to? >>> And no, dumping core is entirely inappropriate in many circumstances. >>> It's the cause of all kinds of messiness in a lot of system services >>> that wind up having to fork off children just in case some piece of >>> code dumps core. >> First, if we're using an imaginary piece of perfect hardware with a >> perfect OS with perfect drivers on a perfect runtime, then we can >> assume that we've made a logical error here, and you very much want to >> dump core and stop doing anything so that the error can be corrected >> or avoided. > > Yes, you've made a logical error. No, the appropriate response isn't to > dump core, but to dump the part of the program that caused the error. How do you know what part of the program caused the error? Basically you make an educated guess. Treating the whole process as the problem seems like a good call. > Put it this way: take your earlier example. You get a division by zero > error. My preference is to catch that exception, clean up, and start > over. You say it's better to dump core, because you can't trust anything > to be perfect. My question for you is: How can you trust that the kernel > will correctly dump your core? I can't, but it is not like I was going to be doing anything useful with the process at that point anyway. >> Let's just say for a second you did catch the error, how would you >> suggest you proceed at this point, if you were again using this >> imaginary system and you did catch a divide by zero error? > > I'll tell you how I do it now: > 1) Collect a stack trace detailing where in the program the error occurred. > 2) Open a socket to the logging server, writing the stack trace. > 3) Close all open files, sockets, and free all global variables. Abort > all processes waiting on a timer. > 4) Delete all temp files of the name patterns this process generates. > 5) Reread the sources to the program, in case it has been fixed, thereby > redefining all the procedures it uses. > 6) Reload all configuration. > 7) Start running again. Seems like you are doing a lot of work that the OS is more than happy to do for you. If you are doing things right, an exit() followed by a fork()/exec() pair would far more effectively doing 1-7. > If I'm writing something like an editor (not necessarily a text editor, > mind), I save out to a different file the current snapshot of what the > user has been working on. While I'm sure it's handy for the programmer > to just dump core, I don't imagine the user would want to be guaranteed > to lose all work. Well, if you dump core, it isn't lost! ;-) Seriously, auto-saving periodically before an unexpected error is detected is way smarter than trying to save the file after it is protected. >> Would you somehow know, despite the unexpected nature of the problem, >> which magical variable needs to be changed to some other value than zero? > > Why would you think that's part of the recovery strategy? It was my best guess as to what would be advantageous about not exiting your process. >> *unexpected* error. Given that you didn't anticipate this problem, how >> do you know that your fix isn't going to do more harm than good? > > How do you know your core dump isn't? I don't. I am just doing the best that I can under the circumstances. > >> Indeed, it tends to be a lot less messy than the alternative. > > Only in operating systems that do the error handling for you. Otherwise, > it's counterproductive. Fair enough. I was assuming one was running on Linux. >> Beyond the import factor that I've highlight, what is the huge >> difference between unwinding a stack until some generalized catch >> block is found that somehow tries to deal with the problem vs. a >> process dying and some parent process with a generalized SIG_CHILD >> handler somehow tries to deal with the problem? > > Nothing. That's why I'm wondering why you think my method is so > dangerous compared to yours. > > The difference is that I can log appropriate messages to the appropriate > places about why it went wrong, I can clean up stuff the OS isn't going > to (like the temp files), and I can decide on the severity of the > problem before taking action. The OS will clean up temp files if you delete upon opening, which is probably the right thing to do if you don't want to risk the file hanging around afterwards. >> C++ makes it entirely possible for you to do things without doing >> anything unspecified. > > Of course it does. That's always the mantra. "It's *possible* to write a > large program without ever making a programming error. Hence, we don't > need to check for programming errors." Oh no. You should check for automatically detectable programming errors. Certainly a perfectly reasonable thing to do is to detect and fail when such things happens. >> If you want, you could add a little lint check in >> your build process that verifies that you always use smart pointers, >> bounds checkers, etc. > > Not really. Only if you restrict yourself to very primitive data > structures. Not at all. I've done it many times and I am in no way restricted as to my data structures. - --Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbdwsOagjPOywMBARAhsIAKCbFxrio3djpgt1BjaE+Fzg0uWwZQCg5ntz gN1eR8tFOdRP/Hkn9nEAREo= =663t -----END PGP SIGNATURE----- -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
