Hi Steffen,
the OOBean is not really maintained for a long time and i would say it
never reached a state where it was really finished. Today i would of
course never suggest to use it because of too many problems that have to
be solved first.
I don't know the code in detail but i know that every developer who
worked on it started to make it better ...
As i mentioned the OOBean is not really maintained and if you have
interest to help out here i will help and support you.
If you are familiar with the OO build env you can start to improve the
error handling and we can discuss your changes. The only thing that i
would suggest is that you keep the interface stable at the beginning.
Further improvements on this level should be postponed to later.
By the way on which platform are you working?
Juergen
Steffen Boersig wrote:
Good morning,
before i start, let me get this clear: It's awesome that you guys do all
that work here. OO is a great product and I defintly appreciate the work
you all have put into it.
Yesterday I encountered several problems while programming with OOBean
and decided to download the source code to get a better understanding
how things are handled inside OO. I solved all my problems through
reading the code so thumbs up here :).
But one thing that bugged me while reading the code was error handling
in the packages.
I knew that the error messages in OO weren't great and always thought
this was due to lazy programming ;) or sometimes there are no better
alternatives. But after reading the code I have to say it's definitly
more of a lazy programming problem when it comes down to error handling
rather than availabilty of alternatives
.
One example:
com.sun.star.comp.beans.LocalOfficeConnection.parseUnoUrlWithOfficePath
The method parses an UnoURL. If everything goes right a state-variable
will be set to 7 and after parsing this state value will be used for
checking if everythings correct. If not, an error will be thrown.
Errors occure on invalid URLs of course and there are several different
errors. All are "catched" in some way since the state value will be set
to a negative number so the check at the end will fail. I counted 6
error states, all indicated through negative numbers.
Well, the problem is: at the end there is only a check if state != 7. An
error will be thrown stateing that the UNO Url is invalid. The 6
different error codes are not used at all. No info on what is invalid
even though the error states could be used to inform the user what was
wrong.
I mean, there is already a kind of exception handling built in, but it
is not used. Why even bother with 6 different error codes if they are
not used for something good?
Of course I didn't check all the source code since most of my problems
could be solved by reading some snippets of the OObean package but I
know for sure, that most exceptions are not really informative compared
to other APIs. And maybe it's a bad example because the method isn't
even used anymore or whatever, I didn't check that. I also don't want to
blame one programmer or make the feature look bad or something like
that. It's just difficult to understand why there is no better exception
handling overall.
Most of the time if something goes wrong, I get an Runtime Error and
that's it. Almost never theres more information given.
I mean, of course I'm able to trace it back anyway. And after reading
some bunch of code and researching the web I get the information I need
to solve the problem, but a more precise exception handling would be
great too.
If I insulted someone with this, I'm sorry. I just wanted to bring this
up since exception handling in OO bothered me and former colleagues for
quite a while now. Maybe it's a food for thought for some of you or a
start for a discussion how it could be made better :) .
Or maybe I just made everyone mad at me :D
Feedback would be appreciated anyway ;).
Regards,
Steffen Börsig
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
