jdb bug and quick fix
Carlos Konstanski <[email protected]> Thu, 08 Nov 2007 20:34:30 -0700
| Newsgroups | gmane.emacs.jdee |
|---|---|
| Message-ID | <87ir4c6qih.wl%[email protected]> |
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