Re: jdb bug and quick fix
Ke Lu <[email protected]> Fri, 09 Nov 2007 22:36:43 +0900
| Newsgroups | gmane.emacs.jdee |
|---|---|
| Message-ID | <[email protected]> |
Carlos Konstanski <[email protected]> writes: > I prefer jdb over jdebug because jdb has enough functionality for 99% > of my debugging needs, and less gizmos and knobs in the way. (Jdebug > is indespensible for some situations.) But there is a bug that > affects code-stepping in jdb. You can step through code, but the > pointer in the left gutter of the source buffer cannot track the > current line because of a stringp type error. The error occurs during > the routine for finding the source buffer. Here's the quick fix: > > In jde-util.el, the function (jde-find-class-source-file) has these as > the first 2 lines: > > (let* ((verified-name (jde-parse-class-exists class)) > (outer-class (jde-remove-inner-class verified-name)) > > This would be good if (jde-parse-class-exists) returned a string, but > it returns a boolean instead. The call to (jde-remove-inner-class) > throws a '(type stringp nil) error as a result. Change the code to: > > (let* ((verified-name (jde-parse-class-exists class)) > (outer-class (jde-remove-inner-class class)) > > `class' is the passed-in string argument to > (jde-find-class-source-file). This is the quick fix. It seems to > work like it needs to. But this makes the logical flow in this > function less than ideal. If we're going to call > (jde-parse-class-exists) to validate the input, we should do something > with that validation before doing more stuff, or fail gracefully. > Something like: > > (if (jde-parse-class-exists class) > (let ((outer-class (jde-remove-inner-class class))) > (do-stuff) > ...) > (signal-no-src-found class)) > > I will try to spend some time refactoring this function and submitting > it for review. > > Carlos Konstanski It seems jdee will be moved to sourceforge this weekend. I agree the jdebugger is not too stable to use and I advice to remove it in the future. Another problem is: jdb in jdee can't work well when The user.language is not en. My advice is: if it is difficult to parse muti-lanuage msg of jdb's output, Please set -J-Duser.language=en to jdb options by hard coding, (including options of nomal debug, attach to socket and attach to share memory)