I like it (the assert) ;-)
But I am not sure about having a completely different
AbstractIOMockSession since we would then be copying code to a certain
degree. I think it would just be cleaner to have the methods protected
so there is no need for code duplication ;-)
What do *you* think? ;-)
Jeff
Emmanuel Lecharny wrote:
> Jeff Genender wrote:
>> Hey guys,
>>
>> I was hoping to see if we could discuss some of the "final" qualifiers
>> on some of the methods in the AbstractIOSession. The reason I ask is it
>> would be cool to be able to override some of the methods such as:
>>
>> public WriteFuture write(Object message)
>> public final int getScheduledWriteMessages()
>>
>> To be able to write MockObjects for unit tests of code. Any thoughts on
>> making these protected instead of final?
>>
>> Thanks,
>>
>> Jeff
>>
>>
> Hi,
>
> makes sense to me... Or we may have a AbstractMockIoSession implementing
> the IoSession interface, for unit tests ?
>
> While looking at the abstract class, I found some methods with this kind
> of code :
>
> public final WriteFuture write(Object message, SocketAddress
> remoteAddress) {
> if (message == null) {
> throw new NullPointerException("message");
> }
> ...
>
> Wouldn't be a perfect case for an assert ? Like :
>
> public final WriteFuture write(Object message, SocketAddress
> remoteAddress) {
> assert message != null : "Null messages are not allowed";
> ...
>
> wdyt ?
>
>
>
