[dev] UNO API exception specifications (was: [dev] Error handling in OOo, shouldn't we show additional info.)
Hi Mathias, However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. +1 Just to play the devil's advocate: without careful considerations that would end in adding throws css.uno.Exception to any method, though perhaps it's the right approach for all generic APIs (generic APIs need generic exceptions - don't they?). Don't think so. I suppose the line is to be drawn (if at all) between ¨high level¨ and ¨low level¨ API (whatever that means :), where the former has an increased chance of throwing a WrappedTargetException (which I'd consider more appropriate than a generic Exception). OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. I would be happy if we would allow for such fixing. I don't want to fix all of those at the same time, but being able to fix them incrementally, as they bite me, would be great. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications (was: [dev] Error handling in OOo, shouldn't we show additional info.)
Hi, On Wednesday, 2009-03-11 09:00:45 +0100, Frank Schönheit wrote: OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. I would be happy if we would allow for such fixing. I don't want to fix all of those at the same time, but being able to fix them incrementally, as they bite me, would be great. Unfortunately, adding exceptions to a method changes the API contract, so fixing things incrementally would incrementally destabilize API use. We'll need some versioned API for this. I guess many are missing such thing and didn't do useful but not required changes for just the reason of API compatibility. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgp9DGyoVExaY.pgp Description: PGP signature
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mathias, When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help read again, please: ¨permanently switched on¨ was what I wrote :) OK, that would be an option that could work. Logging errors until an error handler starts and perhaps creates an error report. But it works with exceptions and IMHO is the more natural approach. I agree with you that it's unfortunate not to have a user compatible way of handling and reporting errors. But we shouldn't clutch at straws and (mis)use something that comes close to that, we should find out what is the right way. User oriented error reporting in many (most?) cases can't be done by taking a message from the point where the exception occured, quite often it needs a context and perhaps even more. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: Without having the bigger picture how good error handling should look like while we are at it, and mentioned UNO incompatibility already ... I just came across (yet) another issue where a severe error was silenced instead of propagated to the caller (and thus caused document corruption), simply because the respective UNO method (XFilter::filter) was poorly designed, and did not allow to throw any but a RuntimeException. However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. +1 Just to play the devil's advocate: without careful considerations that would end in adding throws css.uno.Exception to any method, though perhaps it's the right approach for all generic APIs (generic APIs need generic exceptions - don't they?). While this would be an improvement wrt. being able to fix design flaws, I doubt that this is what we want in every case. It just would create a lot of silently caught exceptions. OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi T. J., May I agree, wholeheartedly? From my own long years of dealing with users (some of them very angry), I conclude that the *error* is what bothers them, not the error *message*. They just want to get their work done. A little techno-babble is only a small point. ... Consider the opposite case, where user and programmer are _under_whelmed by lack of information. A real case: Line 1: Error saving the document filename : Line 2: Error writing file. I would *kill* for a little techno-babble here (for once, I get to wear the angry user hat). Then I could report the bug, with a chance that somebody could fix it, even without a reproducible case. Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. Logging errors is an excellent idea. Keeping such logs short enough to avoid burdening the file system, or performance, but long enough to be useful, is only a small problem, with several possible solutions. But logging is a longer-term enhancement, No. Logging facilities are available, and the same script which produces a add file/line info to exceptions patch could equally easily produce a add logger calls patch. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. See my other mail in response to Stephan's comment, which I saw after I wrote the above ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, For one, end-user oriented exception messages simply do not work in general (think about the category of unchecked or runtime or programmer made a coding mistake exceptions---what use is it for the end user to see a localized Index i=7 was out of bounds of array xyzStrangeList (ranging from 0 to 3)?). For another, common practice *is* to put developer-oriented data into exception messages. For randomly picked evidence of the latter take, for example, a quote from Item 45 of Effective Java: The string representation of an exception should not be confused with a user-level error message, which must be intelligible to end users. Unlike a user-level error message, it is primarily for the benefit of programmers or field service-personnel for use when analyzing a failure. Therefore information content is far more important than intelligibility. (Of course, there is nothing wrong with questioning common wisdom. I just personally think that common wisdom is indeed right here.) And the quote you cited might be an indication I am wrong here :) (though I could try to debate about the difference between an exception's string representation and the exception message :) As a consequence, this would mean that our error handling infrastructure is even worse than I thought: If we cannot use Exception.Message to transport user-messages, or information to *generate* meaningful user messages, then ... With very few exceptions (sic), none our exception classes has additional fields for transporting the necessary information. (Not to mention ... I remember having seen an exception class with an error code field which was not even documented, and used non-UNO SFX-internal error codes. Argh!) So, let's pave our exception messages with techno-babble, for the sake of usability ... who cares :( Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi, Frank (and thank you very much for the explanations), Frank Schönheit - Sun Microsystems Germany wrote: Hi T. J., I would *kill* for a little techno-babble here ... Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. And I see yours: you are worried that the proposed additions will establish squatter's rights on the field, and be hard to evict, should that become desirable in the future. A definite possibility. .. But logging is a longer-term enhancement, No. Logging facilities are available, and the same script which produces a add file/line info to exceptions patch could equally easily produce a add logger calls patch. Sounds wonderful, and should keep everybody happy. 3.0.2? 3.1? [ ;-) ROFL ] /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mathias, When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help read again, please: ¨permanently switched on¨ was what I wrote :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Without having the bigger picture how good error handling should look like while we are at it, and mentioned UNO incompatibility already ... I just came across (yet) another issue where a severe error was silenced instead of propagated to the caller (and thus caused document corruption), simply because the respective UNO method (XFilter::filter) was poorly designed, and did not allow to throw any but a RuntimeException. However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
On 02/26/09 20:40, Frank Schönheit - Sun Microsystems Germany wrote: this is not true for the majority of exception instances (where the exception message is something that can help a knowing person track down the problem, but not something that is meaningful for the average end user---for example, it is always in English). Which I'd consider a bug. If I run an arbitrary macro in Basic which uses the UNO API, any exception which is caught there is reported to the end user. Speaking techno-babble which is not meaningful (I tend to think that Basic developers still are allowed to be, though not necessarily are, average end users) is a usability issue, in my opinion. If Basic does not allow to handle UNO exceptions programatically, this would be a shortcoming of the language or of its UNO binding. It should not, however, be used to create an argument for end-user oriented exception messages. For one, end-user oriented exception messages simply do not work in general (think about the category of unchecked or runtime or programmer made a coding mistake exceptions---what use is it for the end user to see a localized Index i=7 was out of bounds of array xyzStrangeList (ranging from 0 to 3)?). For another, common practice *is* to put developer-oriented data into exception messages. For randomly picked evidence of the latter take, for example, a quote from Item 45 of Effective Java: The string representation of an exception should not be confused with a user-level error message, which must be intelligible to end users. Unlike a user-level error message, it is primarily for the benefit of programmers or field service-personnel for use when analyzing a failure. Therefore information content is far more important than intelligibility. (Of course, there is nothing wrong with questioning common wisdom. I just personally think that common wisdom is indeed right here.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Mathias Bauer wrote: Frank Schönheit - Sun Microsystems Germany wrote: When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help - if an error is hard to reproduce it usually would be gone after switching on the logger after the fact. OTOH, if we had logged the necessary information as part of the exception, the user could save or send it and help us fixing the problem. Mikhail's suggestion is not meant to be a replacement for our suboptimal error handling! But it imposes additional restrictions on a future somewhat-more-optimal solution, thus making it more difficult to design/implement, thus making it even more unlikely (than today) to ever happen. No, it just adds something that can be removed later easily. It does not impose any design constraints on other solutions, especially it does not influence any designs for a better error handling (as it is no real error handling at all). For instance, by putting file/line into the exception message, we will close the door for putting other meaningful information into Exception.Message, because in two years from now on, some people will say that adding other content will break the file/line info feature ... Sorry, I can't take that serious. I don't care for what people will say in a few years, in fact adding line/file information can be removed easily again and it does not prevent adding other stuff in the future. Sure, if you want, you can call it a stopgap solution (that's not the same as a hack!). If you are so interested in getting the real thing, just do it! ;-) But please remember: the most important feature for us is that it must be something that doesn't need activation. If you needed to switch it on, it's too late for those problems we intend to attack. Without having the bigger picture how good error handling should look like, how can we know the suggested solution will fit into this bigger picture, instead of preventing it? As I wrote, this is not about error handling (IMHO a user centric design), it is about user level debugging assistance ( ULDA[TM] ;-)), the stuff you need desperately if things go haywire and you don't have a clue. So far I don't see any reason not to follow Mikhail's suggestion. At least in all projects except dba. ;-) Ciao, Mathias May I agree, wholeheartedly? From my own long years of dealing with users (some of them very angry), I conclude that the *error* is what bothers them, not the error *message*. They just want to get their work done. A little techno-babble is only a small point. Yes, it is possible to overwhelm the user with techno-babble--if we dump 50 or 60 lines of stack trace on them. Adding file-name and line-number doesn't qualify as overwhelming. And, please do not underrate our users. If we were writing a teaching program, aimed at grade-school kids, I would agree that we would need to keep things as simple as possible. But our demographics (from the surveys) show a huge proportion of adults, 20-60 (and a few old geezers like me). They can cope. Consider the opposite case, where user and programmer are _under_whelmed by lack of information. A real case: Line 1: Error saving the document filename : Line 2: Error writing file. I would *kill* for a little techno-babble here (for once, I get to wear the angry user hat). Then I could report the bug, with a chance that somebody could fix it, even without a reproducible case. Notice how useful the wrapper/script solution is, even for those who don't want to use its output. The script produces a nice list of patches (or certainly can be made to), which the programmer can use to check the adequacy of each exception--and then discard! Logging errors is an excellent idea. Keeping such logs short enough to avoid burdening the file system, or performance, but long enough to be useful, is only a small problem, with several possible solutions. But logging is a longer-term enhancement, while wrapping is available quickly, and the two are not mutually exclusive. I suggest doing both. -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mathias, I think that exception messages are not made for end users. As already said, this might be the fundamental point of disagreement between us :) Usually errors and exceptions in programs must be interpreted, put into a context and translated before they can be presented to users. While presenting raw exception messages to users might work in some cases, it won't in the majority of situation where exceptions happen. And especially it doesn't work in case of i/o errors. If an error happens while e.g. a temporary file is written that is just an intermediate step in a process, it won't help the user to tell him what happened. Okay, I see your point here. In Base's code, this is usually solved by chaining exceptions, where a high-level layer throws an own exception describing what happened, and chaining the caught lower-level exception. Admittedly, uno.Exception misses sdbc.SQLException's cool chaining feature :) On the other hand: The translation you describe rarely happens, and nonetheless the exceptions *are* displayed to the user. My favorite example still is the Basic IDE, which you can get easily into displaying NoSuchElementException or IOException without any further info, which is of no help at all to script developer (which happens to be the end user here). OTOH if this is a very rare case that is hard to reproduce, it would be great to have more developer related information that can be reported or automatically sent in an error report. Exceptions are diagnostic tools for developers, and they either can convert them into messages shown to the user (if possible) or handle them in other ways, perhaps by throwing another exception. Enriching the diagnostic message with information that helps developers is very useful, and so adding file names and line numbers would be a relief. Whether it can be logged in a file, in a report or in a details window is of minor importance. Assuming you add file/line to the exception messages. How will users see it, so they can tell you? Either, they explicitly need to switch on some generate additional developer diagnostic information feature - which is what logging thrown exceptions would also allow, and which you say you do not want to require, 'cause of the nondeterministic bugs. Or, the developer diagnostic information is _always_ presented to the user, also to the ones not encountering your nondeterministic bugs, who are not interested in sending you the info. Which I continue to consider a big usability problem (slaying end users with developer babbling). I wouldn't call this a hack. Depends on the intended semantics of Exception.Message. In your interpretation, it might be valid to transport file/line it it. In my interpretation, this would be a hack, since Message is intended for the real message, which would need to be separated from the file/line info. By the way, this separation is highly error-prone, and this is one reason why I call the solution a hack: If you mix file/line with other message content, how will you separate it? If you do not mix it, how will you determine for a given message that it's file/line info? In both cases, how do you *reliably* do this, even for exceptions thrown in third-party components (and passed to your interaction handler)? Too many uncertainties for my taste. IMO, if you need file/line info, use some dedicated file/line info channel. Do not rededicate something which by luck already exists, but was not (canonical) intended for this purpose. (This rededication of something luckily already there and not used otherwise is another point why I call this a hack. And continue to do so, sorry.) So before you can call something a hack, you should present a realistic, cleaner solution that fulfills the same requirements. So: how can we get better diagnostic information in the case of bugs that are hard to reproduce and where we just know that an exception has been thrown somewhere in the code. When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Then, in your code where you throw an exception, log it to this logger. (Currently, loggers always re-create their log file in a new OOo session, but this can be adjusted, of course.) Now if somebody tells you about an error which needs to be diagnosed, tell him to send you the log file. Or even to only look at the last few lines of the log file, and tell you what's written there. This solution shouldn't add too much overhead, assuming that exceptions are, well, exceptional events, and logging itself isn't too expensive. Mikhail's suggestion is not meant to be a replacement for our suboptimal error handling! But it imposes additional restrictions on a future somewhat-more-optimal solution, thus making it more difficult to
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mikhail, My intention was to allow user provide the developer with information that identifies the source of the error. That's understood. It would be useful in case of problems that appear once a year, and look to be mysterious from the first view. Ugly is a taste-related comment, so it is hard to argument for/against it. As for error prone transportation, a screenshot solves this problem easily. The error-prone (and also the ugly, but let's omit that :) related to something else: When you transport the file/line information via the error message, then you need to strip it before you actually display the message to the user. I would consider this an essential requirement, from a user experience point of view. While it is helpful to you as a developer when somebody gives you a screeshot reading Access denied. foobar.cxx, line 134, it is certainly not at all helpful for the average end user who does not intend to send you the screen shot, but is happy with the Access denied message already. Moreover, it is not only not helpful, it will definitely (IMO) alienate the average end user. I think that exception messages are not made for end users. Usually errors and exceptions in programs must be interpreted, put into a context and translated before they can be presented to users. While presenting raw exception messages to users might work in some cases, it won't in the majority of situation where exceptions happen. And especially it doesn't work in case of i/o errors. If an error happens while e.g. a temporary file is written that is just an intermediate step in a process, it won't help the user to tell him what happened. OTOH if this is a very rare case that is hard to reproduce, it would be great to have more developer related information that can be reported or automatically sent in an error report. Exceptions are diagnostic tools for developers, and they either can convert them into messages shown to the user (if possible) or handle them in other ways, perhaps by throwing another exception. Enriching the diagnostic message with information that helps developers is very useful, and so adding file names and line numbers would be a relief. Whether it can be logged in a file, in a report or in a details window is of minor importance. I wouldn't call this a hack. A hack is a somewhat dodgy solution for something that could be implemented in a cleaner way. And - as we are developers creating a product, not people in an acedemic discussion - it should be possible to implement it in an acceptable time frame. So before you can call something a hack, you should present a realistic, cleaner solution that fulfills the same requirements. So: how can we get better diagnostic information in the case of bugs that are hard to reproduce and where we just know that an exception has been thrown somewhere in the code. Mikhail's suggestion is not meant to be a replacement for our suboptimal error handling! Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
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
Re: [dev] Error handling in OOo, shouldn't we show additional info.
On 02/25/09 15:51, Mikhail Voytenko wrote: This is of course nothing new, the discussions regarding better error-handling design can be seen regularly. But in our case, even an information, which exactly exception has caused the problem ( in our scenario there is a high probability that an exception takes place ) would be helpful. On a somewhat related note, also see http://qa.openoffice.org/issues/show_bug.cgi?id=94351 pass information about uncaught/unexpected C++ exceptions to crash reporting. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Frank, On 02/26/09 09:20, Frank Schönheit wrote: 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. My intention was to allow user provide the developer with information that identifies the source of the error. It would be useful in case of problems that appear once a year, and look to be mysterious from the first view. Ugly is a taste-related comment, so it is hard to argument for/against it. As for error prone transportation, a screenshot solves this problem easily. 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. By the way, the rework would take much more time, than the script adding the lines. From this point of view, it is better to let the script run and have at least the line numbers in the messages, than to dream how we change all the extensions in our office. Anyway, I have nothing against adding messages to all the exceptions, if we have resources to do it. I see no conflict between those two tasks. But even if all of them have messages ( thousands of unique messages? ), the filename and linenumber will stay the best unique identifier, as actually assertions prove. 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. Completely agree, we should. But again, I would not mix those two solutions.. 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. This is a nice solution. It would help in our case, although the minus is that it has to be turned on before the problem happens. And some problems of the mentioned kind, are hardly reproducible. Thanks, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, On 02/26/09 09:28, Stephan Bergmann wrote: On 02/25/09 15:51, Mikhail Voytenko wrote: This is of course nothing new, the discussions regarding better error-handling design can be seen regularly. But in our case, even an information, which exactly exception has caused the problem ( in our scenario there is a high probability that an exception takes place ) would be helpful. On a somewhat related note, also see http://qa.openoffice.org/issues/show_bug.cgi?id=94351 pass information about uncaught/unexpected C++ exceptions to crash reporting. I have added a comment to the issue. This is from my point of view another argument to have the file name and line information in the exception. Best regards, Mikhail. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mikhail, My intention was to allow user provide the developer with information that identifies the source of the error. That's understood. It would be useful in case of problems that appear once a year, and look to be mysterious from the first view. Ugly is a taste-related comment, so it is hard to argument for/against it. As for error prone transportation, a screenshot solves this problem easily. The error-prone (and also the ugly, but let's omit that :) related to something else: When you transport the file/line information via the error message, then you need to strip it before you actually display the message to the user. I would consider this an essential requirement, from a user experience point of view. While it is helpful to you as a developer when somebody gives you a screeshot reading Access denied. foobar.cxx, line 134, it is certainly not at all helpful for the average end user who does not intend to send you the screen shot, but is happy with the Access denied message already. Moreover, it is not only not helpful, it will definitely (IMO) alienate the average end user. (Access denied might be a bad example, since this end-user message is probably generated from some error code, and not an actual exception message, but I hope you get the idea.) As a consequence, you *must* strip the file/line info before displaying the message, and this is what I called error-prone. (If I had a wish, I'd vote for changing UNO incompatibly, and adding a Stack member to the css.uno.Exception class instead. Oh, well, just dreaming :) By the way, the rework would take much more time, than the script adding the lines. From this point of view, it is better to let the script run and have at least the line numbers in the messages, than to dream how we change all the extensions in our office. s/extensions/exceptions/, I suppose? Well ... I hate to say that, but the approach you suggest is clumsy, in my opinion, for the reasons outlined above. And the argument We do not have the time/resources to make it right, let's do it the quick and dirty way instead is something which I hear too often (and suffer from too often, months or years later), for my taste. But okay, that might be only me. In any case, I *strongly* suggest you ask user experience what they think about slaying end users (who do not want to send you the screenshots) with file/line information. But even if all of them have messages ( thousands of unique messages? ), the filename and linenumber will stay the best unique identifier, as actually assertions prove. One other note: Did you try how this adds to library size, if all those exceptions are padded with additional strings? Don't want to say it's not bearable, just wanted to mention that you should keep an eye on this, too. Completely agree, we should. But again, I would not mix those two solutions.. See above. In my opinion, the one solution is not a solution, but a hack only :) [logging] This is a nice solution. It would help in our case, although the minus is that it has to be turned on before the problem happens. And some problems of the mentioned kind, are hardly reproducible. Reproducibility is a problem indeed. Seeing that our latest versions towards 3.1 have this OpenOffice.org improvement program feature, where user actions are anonymously logged, I wonder whether log all thrown exceptions is something which belongs to OpenOffice.org improvement, too. That is, if a user volunteers to let OOo collect data which helps us making OOo better, why not also logging the thrown exceptions then? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: (If I had a wish, I'd vote for changing UNO incompatibly, and adding a Stack member to the css.uno.Exception class instead. Oh, well, just dreaming :) Hi Frank, nah, please stick to that, there *must* be something out there that *is* important enough to change UNO incompatibly (and then to sneak in all the other incompatible changes I'm dreaming of)... ;) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
On 02/26/09 14:01, Frank Schönheit - Sun Microsystems Germany wrote: While it is helpful to you as a developer when somebody gives you a screeshot reading Access denied. foobar.cxx, line 134, it is certainly not at all helpful for the average end user who does not intend to send you the screen shot, but is happy with the Access denied message already. Moreover, it is not only not helpful, it will definitely (IMO) alienate the average end user. Even if there happen to be exception instances where the exception message is designed to be meaningfully presented to an end user (do you indeed use localized exception messages?) this is not true for the majority of exception instances (where the exception message is something that can help a knowing person track down the problem, but not something that is meaningful for the average end user---for example, it is always in English). For the latter, I see no problem with augmenting the exception message with file and line information (other than the ugliness inherent in C/C++ macros). For the former, you should simply exempt those instances from Mikhail's wholesale macrofication, I would say. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, Even if there happen to be exception instances where the exception message is designed to be meaningfully presented to an end user (do you indeed use localized exception messages?) (yes, indeed, we do) this is not true for the majority of exception instances (where the exception message is something that can help a knowing person track down the problem, but not something that is meaningful for the average end user---for example, it is always in English). Which I'd consider a bug. If I run an arbitrary macro in Basic which uses the UNO API, any exception which is caught there is reported to the end user. Speaking techno-babble which is not meaningful (I tend to think that Basic developers still are allowed to be, though not necessarily are, average end users) is a usability issue, in my opinion. For the latter, I see no problem with augmenting the exception message with file and line information (other than the ugliness inherent in C/C++ macros). For the former, you should simply exempt those instances from Mikhail's wholesale macrofication, I would say. I suppose our fundamental question indeed is whether Exception.Message is an end-user feature, or a diagnostic means. If it's the latter, then file/line are well suited there - but it's this premise I doubt. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Error handling in OOo, shouldn't we show additional info.
Hi All, While discussing with Mathias a mysterious non-reproducible problem, we came again to conclusion that OOo error handling is not the best one from the developer point of view. It is quite hard to understand what exactly goes wrong sometimes. This is of course nothing new, the discussions regarding better error-handling design can be seen regularly. But in our case, even an information, which exactly exception has caused the problem ( in our scenario there is a high probability that an exception takes place ) would be helpful. 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. In case of exceptions that have no arguments ( and we have many of such cases ), 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. 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. 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. Best regards, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
