home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / scheme / 2107 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.5 KB  |  59 lines
  1. Newsgroups: comp.lang.scheme
  2. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!ames!pasteur!volga.Berkeley.EDU!matt
  3. From: matt@volga.Berkeley.EDU (Matt Wright)
  4. Subject: Re: wots going on here!?
  5. Message-ID: <1992Aug30.182548.13079@pasteur.Berkeley.EDU>
  6. Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
  7. Nntp-Posting-Host: volga
  8. Organization: University of California, at Berkeley
  9. References: <JINX.92Aug29223329@chamarti.ai.mit.edu> <17piphINNncj@agate.berkeley.edu> <JINX.92Aug30102323@chamarti.ai.mit.edu>
  10. Date: Sun, 30 Aug 1992 18:25:48 GMT
  11. Lines: 46
  12.  
  13. In article <JINX.92Aug30102323@chamarti.ai.mit.edu> jinx@zurich.ai.mit.edu writes:
  14. >In article <17piphINNncj@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
  15. >
  16. > [Don't put me in the debugger or a special environment on error unless
  17. >  I ask for it.]
  18. >
  19. >I'm sorry, but I disagree strongly with this view of the world.
  20. >It is very close to the C/Unix printing "segmentation violation (core
  21. >dumped)" and giving you back a shell prompt.
  22. >
  23. >Your answer of having to tweak a flag or whatever is analogous to
  24. >saying "recompile and run it under the debugger".
  25.  
  26. I disagree.  You way is analogous to having it be so that typing "mial"
  27. instead of "mail" opens up a new shell with a fresh set of environment
  28. variables and puts you into the debugger, instead of printing an error
  29. message and giving you another prompt.
  30.  
  31. Simple, stupid typing mistakes account for 90% of the errors I generate;
  32. most of the rest come from stupid stuff like forgetting the order of
  33. arguments to a function.  If I'm really looking hard and trying to find an
  34. elusive bug, I'll be more careful and turn on the debugger.
  35.  
  36. >Please remember that there are programs that modify global state,
  37.  
  38. Not until chapter 3...  :-)
  39.  
  40. >and thus re-running is not an option since they may not fail in the same 
  41. >way or at all.
  42.  
  43. Yes, that it a problem.  But this is the kind of situation where you'll be
  44. more careful and possibly turn on the debugger.  In my experience, when I
  45. debug some non-functional program, I end up writing a "reset" procedure that
  46. gets all my state information set up correctly; I run that before testing my
  47. real program.
  48.  
  49. Besides, what we're talking about is making life easier for beginning users,
  50. who tend not to modify global (or local) state anyway.
  51.  
  52. But I agree that's it's a tradeoff.  I *have* been in the situation where I
  53. generated an error and wished I could get back to that context, but I got
  54. thrown back to top-level.  Somebody should write a DWIM debugger that
  55. heuristically determines if your error is "interesting"... :-)
  56.  
  57. -Matt
  58.  
  59.