Skip to main content

Feature Request -- Better Exception Handling, especially in PropertySetter

1 reply [Last post]
Joined: 2003-06-15

A lot of the exception handling in PropertySetter looks like this (from the begin() method):

} catch (Exception e) {
System.out.println("Problem with propertySetter in ObjectModifier");

Better to have some useful information about fixing the problem. "ObjectModifier" only appears in these System.out.println strings.
Better to print the message to System.err or to a log.
Better to print the message from the exception, and the stack trace.
Best would be to include a way to install an exception handler based on an interface, so we can customize it ourselves.

(I'd hoped to put together an easy patch, but my Netbeans is not like your Netbeans. Sorry.)



Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-08-07

Hi Dave,

Thanks for the problem report. I'm thinking this is going to be the final bug fix before I finally post a 1.0 on this sucker (it's been stable for a while, and awaiting a "1.0" monicker just because I haven't gotten around to it yet).

In terms of the actual problem and suggested fixes:

- The weird "ObjectModifier" language is a holder from a previous version of the library, where PropertySetter was actually two objects, ObjectModifier and PropertyRange. Apparently, my refactoring into PropertySetter was not complete (maybe they should call it "refractoring" instead?)

- I'll add at least the exception message - I agree that it's not helpful just getting an error message here.

- I don't like using System.err in general, mostly because it doesn't work well with DOS. You can force DOS to pipe System.out to a file, but not System.err. So I tend to use System.out overall, even for error conditions. (Isn't it nice how Windows pervades the way we think and work?)

- Not sure about the stack trace. I think at least the exception message, but that generally lists the stack trace along with it. I've found that once you start inserting random Thread.dumpStack() calls in your code, any output tends to get lost in spews of stack traces.

- An exception interface is homework for another day - I'll fix the egregious problem right now of printing out the right information, but I'm not up for major contortions in the library at this point.