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

Reply via email to