At 4:55 PM +0900 2/22/07, Robert K. wrote:
Exceptions are tough since Ruby does not have checked exceptions.
And because of Ruby’s dynamic nature it’s practically impossible
to determine which exceptions can be thrown by a method.
Ruby’s dynamic nature presents all sorts of obstacles, to be sure.
Nonetheless, there ARE some possibilities:
- Rescue clauses can be recognized and tracked.
- Exception use can be recorded in a logfile and analyzed.
In Callbacks, not sure what you mean here. You can view every
block passed to a method as callback. What do you want to document
about this?
I’m a bit vague about this myself. Certainly, if the program sets
up a callback to Module#method_added (etc), we can track this.
Variables: if you refer to local variables …
Agreed. Local variables are only interesting in so far as they can
be confused for method calls.
By “looks” do you mean “has a rescue clause for”? That is certainly
easier to do than determining which exceptions are thrown by a method.
However, I think the latter info is much more useful as it affects
the caller.
As noted above, determining which exceptions are thrown by a method
can be tracked through execution logging. Of course, we then get
into the usual problems of code coverage, etc. I’ve got some logging
code started for this sort of thing, but I’d rather concentrate on the
things that can be determined through static analysis, for now.
Then, I’d like to store the information in a computer-friendly form,
such as a set of DB tables, so they can be accessed by a Rails app, etc.
To do what? Sorry, I still don’t understand what you want to achieve.
As I said, my motivation is to extend RDoc’s coverage and utility. If
the information gathered by RDoc (etc) can be stored in an accessible
form (e.g., DB tables), it should be possible to build some Rails code
that can allow the user to browse it, diagram relationships, etc.
RDoc is handy, but it doesn’t provide anything like the feature set of
(say) Doxygen. Also, it pays no attention to information that can be
gathered from Rails apps: method references in rhtml files, conventions
in file naming, etc. So, the general plan is to gather the information
that I can, store it in a DB, and see what useful displays I can create.
-r
http://www.cfcl.com/rdm Rich M.
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development