Re: [dev] UNO API exception specifications
Frank Schönheit - Sun Microsystems Germany wrote: Not sure we need versioning, but we definitely need to way to (carefully) break compatibility. As I've been told, this has been a topic on this week's engineering steering committee meeting ... I think we never will allow breaking compatibility at arbitrary points in time, but rather allowing for some controlled big bang changes, like e.g. at a major release. That would mean that the changes we are talking about must be collected and prepared so that they are ready at the big bang event. OTOH this means that every deveveloper must be able to plan for that and so we need a long running schedule for that. I think this would be a good compromise. If something bites me for years, it is bearable to wait for just a few more months before it can be fixed. Regards, 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] UNO API exception specifications
Frank Schönheit - Sun Microsystems Germany wrote: Hi Rony, *The former: it is just frustrating to have a program bomb and get a message like exception occurred. (Yielding the message: go, figure...)* which nicely fits into the original thread :) Fixing those exceptions (which I consider buggy in the current messageless-shape) to carry a meaningful message would address the original problem of the thread as well as the API consumer's problems. (MM: Sorry, could not resist :) No problem, I agree. The message should be helpful for the API consumer, means: the developer of the client code. Not necessarily the user. :-P This is the job of the client code's developer who knows the context of the API call that failed. 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
[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] UNO API exception specifications
Hi Eike, 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. what do you mean by destabilize? The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). Nonetheless, I think that's manageable. (Side note: If the tool generating our C++ headers would have the - long-desired - feature to create a ¨#define DECLARE_XFOO¨, then the problem would be less severe, as then a simple recompilation would adjust the headers, and the not-adjusted source files would simply break during compilation.) 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. Not sure we need versioning, but we definitely need to way to (carefully) break compatibility. As I've been told, this has been a topic on this week's engineering steering committee meeting ... 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
On 03/11/09 11:43, Frank Schönheit - Sun Microsystems Germany wrote: The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). What about language bindings other than C++? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Stephan, The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). What about language bindings other than C++? Basic an Python ignore are not affected by changed exception specifications, as far as I understand. Java code would need to be recompiled, which would break until the code is adjusted (right?). However, this is probably something on the ¨to-be-accepted¨ list, if we allow for such a change in the UNO API (and this allowance was my premise for this discussion). What other language bindings are there? 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
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). What about language bindings other than C++? Basic an Python ignore are not affected by changed exception specifications, as far as I understand. Java code would need to be recompiled, which would break until the code is adjusted (right?). However, this is probably something on the ¨to-be-accepted¨ list, if we allow for such a change in the UNO API (and this allowance was my premise for this discussion). What other language bindings are there? Out of the box BeanShell, JavaScript, and at least ooRexx in addition. All of these use the Java bridge, if I am not mistaken. The ooRexx binding would not have a problem at all with such a change, that I would regard of utmost importance. [Yes, I wholeheartedly agree, that the current situation is many times frustrating, especially for beginners in an area of OOo (even experts of one or two modules are beginners if turning to new modules). There is a lot of resources that is being wasted just to figure out what the original cause of an exception was, if possible at all.] ---rony
Re: [dev] UNO API exception specifications
On 03/11/09 15:12, rony wrote: [Yes, I wholeheartedly agree, that the current situation is many times frustrating, especially for beginners in an area of OOo (even experts of one or two modules are beginners if turning to new modules). There is a lot of resources that is being wasted just to figure out what the original cause of an exception was, if possible at all.] With figure out do you mean programatically (catching an exception and trying to handle it, but having problems distinguishing the different kinds of exceptions that got lumped together as runtime exceptions due to missing exception raising specifications at UNO methods) or a programmer trying to understand a situation where an exception was thrown? In the latter case, I would not see how Frank's proposal (change published UNO interfaces incompatibly by changing their method's exception raising specifications) would help here. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Stephan Bergmann wrote:
On 03/11/09 15:12, rony wrote:
[Yes, I wholeheartedly agree, that the current situation is many
times frustrating, especially for beginners in an area of OOo (even
experts of one or two modules are beginners if turning to new
modules). There is a lot of resources that is being wasted just to
figure out what the original cause of an exception was, if possible
at all.]
*With figure out do you mean programatically (catching an exception
and trying to handle it, but having problems distinguishing the
different kinds of exceptions that got lumped together as runtime
exceptions due to missing exception raising specifications at UNO
methods)* o/r a programmer trying to understand a situation where an
exception was thrown/? In the latter case, I would not see how
Frank's proposal (change published UNO interfaces incompatibly by
changing their method's exception raising specifications) would help
here.
*The former: it is just frustrating to have a program bomb and get a
message like exception occurred. (Yielding the message: go, figure...)*
/The latter case you cite would eventually help too, if the new
exceptions carry meaningful/helpful information via the exception('s
type); this may do wonders helping the developer to quickly (or more
quickly) identify the nature/cause of problems and either fix it right
away or becoming able to jump-start the necessary research in a concrete
corner of the documentation or area of the code. /
---rony
P.S.: Sorry, used the openoffice-e-mail address which does not work
(posting held, moderator intervention needed).
Re: [dev] UNO API exception specifications
Stephan Bergmann wrote:
On 03/11/09 15:12, rony wrote:
[Yes, I wholeheartedly agree, that the current situation is many
times frustrating, especially for beginners in an area of OOo (even
experts of one or two modules are beginners if turning to new
modules). There is a lot of resources that is being wasted just to
figure out what the original cause of an exception was, if possible
at all.]
*With figure out do you mean programatically (catching an exception
and trying to handle it, but having problems distinguishing the
different kinds of exceptions that got lumped together as runtime
exceptions due to missing exception raising specifications at UNO
methods)* o/r a programmer trying to understand a situation where an
exception was thrown/? In the latter case, I would not see how
Frank's proposal (change published UNO interfaces incompatibly by
changing their method's exception raising specifications) would help
here.
*The former: it is just frustrating to have a program bomb and get a
message like exception occurred. (Yielding the message: go, figure...)*
/The latter case you cite would eventually help too, if the new
exceptions carry meaningful/helpful information via the exception('s
type); this may do wonders helping the developer to quickly (or more
quickly) identify the nature/cause of problems and either fix it right
away or becoming able to jump-start the necessary research in a concrete
corner of the documentation or area of the code. /
---rony
Re: [dev] UNO API exception specifications
Hi Rony, *The former: it is just frustrating to have a program bomb and get a message like exception occurred. (Yielding the message: go, figure...)* which nicely fits into the original thread :) Fixing those exceptions (which I consider buggy in the current messageless-shape) to carry a meaningful message would address the original problem of the thread as well as the API consumer's problems. (MM: Sorry, could not resist :) 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
