Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | setName(name) on a bookmark throws an undocumented RuntimeException if the name already exists | ||
---|---|---|---|
Product: | Writer | Reporter: | clutz <chrlutz> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | ACCEPTED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | baumux, chris_mux, issues, kpalagin, mux2005 |
Version: | OOo 2.0.2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
clutz
2006-09-20 16:25:19 UTC
Reassigned to JSK. Confirming with OO 2.0.4 on Win XP - code throws an exception. API -> cn css.container.XNamed does not throw a special exception. This is a design issue in the css.container.XNamed idl and can not be fixed anymore. But css.uno.RuntimeException is allowed as back door. See correspond idl. => invalid this is still a documentation issue as the service css.text.Bookmark implements the Interface css.container.XNamed, but the described behaviour is not documented in the corresponding idl-description. The documentation of css.text.Bookmark should clearly state that renaming a bookmark leeds to a RuntimeException if the name already exists. I dont think this behaviour is intuitive and consistent, as other implementations might be able to dissolve name conflicts. In fact there are methods that behave more inteligent in case of name conflicts (eg. when creating a new Bookmark with a name that already exists, the new name is "name <number>"). So I think it's worth to document this behaviour in the service that implements XNamed. cn->jsc : please take over jscv -> tl: can you please document the behavior at the Bookmark service. The interface XNamed doesn't mention conflicts. It just requires the object's name to be unique within the container. The documentation of css::container::XNamed should be improved. From my POV it is no acceptable solution to reinterprete the Name argument into some arbitrary Name+<index> argument. The caller of a function must be able to rely on the result of the operation. If I call setName("x") and the function doesn't throw then the object _must_ be names "x" now. The user of this interface has to check the container if a name is already in use. Has become a documentation issue. |