Hi Mikhail, > The first idea was to provide information similar to the assertions. > Each extension could use the macros wrapping the existing text and > adding the file name and line number. Since usually the text is based on > the constant string literal, the generation of the string would not > affect the performance.
As much as I agree that error handling needs to be improved, I don't like the idea to "pollute" exception messages with information about the file where the exception happened. This information should be separated from the mere message, since the latter is (potentially) to be shown to the user, but the former usually isn't. But perhaps I get you wrong here, since you also talk about a "details" window provided by the InteractionHandler, which would imply that either the handler needs to strip the error location from the message (ugly and error prone), or that you want to transport the location by other means than by appending it to the message. > In case of exceptions that have no arguments ( and we have many of such > cases ), Shouldn't we change those exceptions to actually *contain* a message? And, more important, teach ourself to *not* throw exceptions which do not contain a message? If our exceptions had a message, it would be easy to search for the message in our code base, and find the place where it is thrown. As said above, exception messages are often displayed to end users (imagine Basic scripts), so I always strongly disliked the "throw FooException()" places, since this results in "FooException." being displayed to the end user, which is in no way helpful, and simply a usability bug. So, to make it short: We should provide meaningful error messages when throwing exceptions, this would solve the problem, too, in an even broader context. > we could use a default macro for each type of extension, that > would not take so much time I think. That could be actually done by a > relative simple script. Don't let that script run over my modules, I continue to consider places without a message a bug, and prefer fixing this bug instead :) > In result the InteractionHandler could get the requests containing > additional information. This information could be shown in a kind of > "details..." subwindow of the error message. There were already > suggestions from UX to extend the error messages with such a "details" > window. The framework and applications also would have a chance to > provide this additional information in this way. See above - how should this additional information be transported, if not mangled into the Message member? > In general it looks from the first view to be realistic even for OOo3.2. > From other side it is only a very quick first view, so any suggestions, > corrections and etc are very welcome. http://wiki.services.openoffice.org/wiki/Category:Logging We have good experiences with this. For instance, our JDBC->SDBC bridge is paved with logger calls. When logging (for this particular logger) is not enabled, then this costs nearly no time, since it is just about noticing that nothing needs to be logged. However, when it is enabled, then the result is a log file which we can use to examine what went on on the user's machine (Since the user has to explicitly enable this, and send us the log file, this isn't a privacy problem). In particular, the component has a central method for throwing exceptions, and there, all to-be-thrown exceptions are logged. Together with method entry guards ("enter foo( bar )", "leaving foo with result x"), this allows a pretty good analysis. So, my suggestion would be to create dedicated loggers for your components, and log the to-be-thrown exceptions. Of course, you then cannot display this information to the user in OOo's UI. However, I strongly doubt that information like "This exception was thrown in SomeClass::doSomething() line 12345" is really something which belongs into the UI. That's a diagnostic, and diagnostics are nothing you should slay Joe Average with. (And no, hiding diagnostics behind a "Details" button doesn't really make it better.) For diagnostics, use a dedicated diagnostics channel, which can be enabled by the experienced/willing user on request. Just my 2^W50 cents. Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
