Hi, Well, it was mainly me because the DataItemException and other generic exceptions were itching me for some time especially during unit testing. I deliberately choose MWException as deriving class for the time being because a lot of work needs to be done in order to get SMW to a stage where unit testing can show its true impact and Exception handling (especially those newly created with proper test coverage) has not found any real love.
For example, currently only 33.33 of the SMW code base is covered which means anyone who cares is surely invited to pitch in. - Separate classes (compartmentalize and assign specific responsibilities) to avoid having to deal with a "god" object [1] - Improve general test coverage - Modify existing classes in order to be able to inject objects rather than assuming those objects are available during execution - Separating MW specific objects from SMW's core implementation (related to MWException ) - DBStoreIntegrationTests, most unit tests (written during the lost three month or so) use mock objects to avoid running tests against a specific DB environment (unit tests should not care for any specific DB environment unless absolutely necessary) therefore SMW DBStoreIntegrationTests are missing. PS: When relying on InvalidArgumentException you get an error message outside of MW's skin display where MWException generates the exception message within the current skin. [1] http://en.wikipedia.org/wiki/God_object Cheers On 7/23/13, Jeroen De Dauw <jeroended...@gmail.com> wrote: > Hey, > > I noticed some work was done on exceptions in SMW recently - nice :) > > A few thoughts on how it can be further improved: > > Right now they all derive from MWException, not sure what good this does. > This creates binding to MW all over the place, while this is probably not > needed anywhere. > > At least for DataItems, special "DataItemException" are thrown for any kind > of error in those classes. While most of those errors seem to be either > input issues, where usage of InvalidArgumentException would be better, or > deserialization issue, for which a dedicated > DataItemDeserializationException might be more appropriate. For instance, > this later one could have an extra field that holds the invalid > serialization (would be awkward to just stuff this into the exception > message). > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel