About that testing, I might put some time into cleaning up sonar issues and improving core test coverage.
Cheers, Francis On Thu, Jan 27, 2011 at 9:53 AM, Rainer Döbele <[email protected]> wrote: > Hi Francis, > > yes I myself have asked this question a while ago, whether we should keep > this old style error handling as an option. > Currently we can switch between Exception-mode and an exception-less mode > with Boolean return values for most functions to indicate an error. > > I agree that this exception-less mode is not really needed and I have no > problem getting rid of it and only do Exceptions in the future. However it > only makes sense if we also change the return values of most functions and > thus there is a lot to rethink an test - which means quite a bit of work. > > I would suggest to leave it for now until we have finished our 2.1. release. > This should then be a major task for a 2.2. release. > > I thought we have an issue for this already but could not find any. > I have now changed EMPIREDB-95 which was "Code cleanup and review" (did quite > mean anything) to "Remove optional support for old style error handing". > > Regards > Rainer > > > Francis De Brabandere wrote: >> from: Francis De Brabandere [mailto:[email protected]] >> to: [email protected] >> re: Re: [jira] Updated: (EMPIREDB-97) Serialization of Empire-DB >> objects >> >> Rainer, >> >> We probably already had a discussion about this ErrorObject idea. I >> still see this as some kind of anti-pattern from old times where >> inheritance was the key to everything. >> >> Could you (again) explain me what the added value of this ErrorObject >> is (ignoring backwards compatibility)? I'll add that info to the wiki >> in case I forget once again or somebody else asks the same question. >> >> Cheers, >> Francis >> >> On Wed, Jan 26, 2011 at 11:36 PM, Rainer Döbele <[email protected]> >> wrote: >> > Hi Eike, >> > >> > I can follow your conclusion and agree that making ErrorObject >> serializeable makes no sense (why would anyone want to serialize an >> error anyway?), whereas serializing EmpireException is fine. >> > >> > I have not applied your patch yet (but I will do), but there is one >> more thing that came to my mind: >> > DBReader is not serializeable as it requires a reference to an open >> java.sql.ResultSet. >> > We have to make sure, that that a NotSerializeable exception is >> thrown, when attempting to serialize this class. >> > >> > Thanks and regards, >> > Rainer >> > >> > >> > Eike Kettner (JIRA) wrote: >> >> from: Eike Kettner (JIRA) [mailto:[email protected]] >> >> to: [email protected] >> >> re: [jira] Updated: (EMPIREDB-97) Serialization of Empire-DB >> >> objects >> >> >> >> >> >> [ https://issues.apache.org/jira/browse/EMPIREDB- >> >> 97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> >> >> Eike Kettner updated EMPIREDB-97: >> >> --------------------------------- >> >> >> >> Attachment: 1_dbobject.patch >> >> 0_exception.patch >> >> >> >> Hi there, >> >> >> >> As I started working on the serialization thing, I figured that it's >> >> not a good idea to let ErrorObject implement Serializable. Nearly >> every >> >> object extends ErrorObject and for some (and especially for objects >> to >> >> come) it is not desireable to be serializable. I think its not that >> >> good >> >> to open so many object for serialization. Then there are already >> >> classes >> >> that hold non-serializable references (I found XMLConfiguration to be >> >> such a class). So, I think it could be a source of bugs to open every >> >> object this way... >> >> >> >> The other side is, that ErrorObject uses a static ThreadLocal to hold >> >> error info. This wouldn't be serialized anyways. This means >> >> EmpireException wouldn't be serializable even if ErrorObject >> implements >> >> Serializable. >> >> >> >> Instead I chose to serialize EmpireException by using a serializable >> >> implementation of ErrorInfo. The major difference here: >> EmpireException >> >> does not hold a reference to the concrete object anymore, but only a >> >> copy of the error infos. IMHO, this is good for an exception, but I >> >> have >> >> no glue to what extend users rely on EmpireException#getErrorObject >> to >> >> return a DBTable, XMLConfiguration etc. This is applied with the >> first >> >> patch. >> >> >> >> Then I chose to let DBObject implement Serializable. I think that >> it's >> >> nice if data model objects are serializable. Plain SQL strings are >> >> serializable and so I think objects like DBCommand or DBOrderByExpr >> >> (that represent parts of SQL) should be serializable, too :). This is >> >> applied in the second patch. >> >> >> >> Regards, >> >> Eike >> >> >> >> >> >> > Serialization of Empire-DB objects >> >> > ---------------------------------- >> >> > >> >> > Key: EMPIREDB-97 >> >> > URL: >> https://issues.apache.org/jira/browse/EMPIREDB- >> >> 97 >> >> > Project: Empire-DB >> >> > Issue Type: Wish >> >> > Components: Core >> >> > Reporter: Eike Kettner >> >> > Attachments: 0_exception.patch, 1_dbobject.patch >> >> > >> >> > >> >> > Looking at class EmpireException, it holds references to two non- >> >> serializable objects: ErrorObject and ErrorType which breaks the >> >> contract with the Exception API. >> >> > Now, it would be great for several use-cases to have Empire-DB >> >> objects serializable. If ErrorObject would be serializable, it would >> >> first make EmpireException serializable (assuming ErrorType to be >> >> serializable) and next it would make every other DBXyz object in this >> >> hierarchy serializable. >> >> > Here is for reference the mail thread from users@ mailing list: >> >> > ------------------------------ >> >> > On Sat, Jan 22, 2011 at 7:26 PM, Eike Kettner <[email protected]> >> wrote: >> >> > > Hi Rainer and Francis, >> >> > > >> >> > > thanks for your quick replies and for giving this a chance. >> >> Serializing >> >> > > an exception is sure not something massive used, however >> sometimes >> >> it is >> >> > > quite a nice feature. For example, a JMSLogger sends log events >> to >> >> a >> >> > > broker, and there exceptions are serialized. Well, I see that >> this >> >> is >> >> > > not used often, and more or less a "special case" :). Still, I >> >> would >> >> > > consider a non-serializable exception a small "bug" - just >> because >> >> it's >> >> > > dictated by the java api. >> >> > > >> >> > > I had a quick look at the sources and as far as I can see, it >> >> should be >> >> > > ok to make "everything" serializable. There is always the >> >> > > "serializable-drawback" to consider: users can save objects on >> disk >> >> and >> >> > > later try to load them with a new version of empire-db, where >> class >> >> > > definitions have changed. Well, I think one can live with this, >> and >> >> it >> >> > > does not apply to many other use-cases of serialization (rmi, >> >> > > serialization used in wicket or messaging), because objects are >> >> > > serialized only for a short amount of time. >> >> > > >> >> > > Regards, >> >> > > Eike >> >> > > >> >> > > On [Sat, 22.01.2011 13:49], Rainer D=F6bele wrote: >> >> > >> Hi Eike, >> >> > >> >> >> > >> I agree with Francis that I don't quite see the point for >> >> serializing an Exception, although I must admit that >> >> java.lang.Throwable is Serializable. >> >> > >> >> >> > >> But then I agree that we should consider making DBObject or >> >> ErrorObject serializeable which then would apply to the entire object >> >> hierarchy. >> >> > >> Regards >> >> > >> >> >> > >> Rainer >> >> > >> >> >> > >> >> >> > >> Francis De Brabandere wrote: >> >> > >> > from: Francis De Brabandere [mailto:[email protected]] >> >> > >> > to: [email protected] >> >> > >> > re: Re: Serialization of EmpireException >> >> > >> > >> >> > >> > Hi Eike, >> >> > >> > >> >> > >> > I see no reason for not making them Serializable. >> >> > >> > >> >> > >> > Rainer? >> >> > >> > >> >> > >> > Cheers, >> >> > >> > Francis >> >> > >> > >> >> > >> > On Fri, Jan 21, 2011 at 4:31 PM, Eike Kettner <[email protected]> >> >> wrote: >> >> > >> > > >> >> > >> > > Hello, >> >> > >> > > >> >> > >> > > I was trying to serialize EmpireException but ran into an >> >> error. >> >> > >> > > EmpireException is marked as Serializable (RuntimeException) >> >> > >> > > but it holds references to ErrorObject and ErrorType which >> are >> >> not >> >> > >> > > serializable. Hence a NotSerializableException is thrown. >> >> > >> > > >> >> > >> > > When asking this, I like to ask whether there is a thought >> >> about making >> >> > >> > > some model objects like DBRowset DBTable etc serializable. >> >> Since most or all >> >> > >> > > DBXyz objects hold model information only it should be okay >> >> for them to >> >> > >> > > be serializable, imho? I use messaging and often Apache >> Wicket >> >> which >> >> > >> > > both use serialization, that's why I'm asking this. (For >> >> example, I'd >> >> > >> > > like to pass around where and order-by expressions). >> >> > >> > > >> >> > >> > > Kind Regards, >> >> > >> > > Eike >> >> > >> > > >> >> > >> > > >> >> > >> > > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > -- >> >> > >> > http://www.somatik.be >> >> > >> > Microsoft gives you windows, Linux gives you the whole house. >> >> > >> >> >> > > >> >> >> >> -- >> >> This message is automatically generated by JIRA. >> >> - >> >> You can reply to this email to add a comment to the issue online. >> > >> > >> >> >> >> -- >> http://www.somatik.be >> Microsoft gives you windows, Linux gives you the whole house. > -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house.
