Re: [MINA 3] IoBuffer
On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/27/11 10:18 PM, Christian Schwarz wrote: ...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). Right ! Btw, I will implement the missing code soon, so it's just a placeholder atm. We bneed commons coding rules because I used new RuntimeException(not implemented) Julien
[Mina 3] exceptions was Re: [MINA 3] IoBuffer
On 11/28/11 9:43 AM, Julien Vermillard wrote: On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/27/11 10:18 PM, Christian Schwarz wrote: ...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). Right ! Btw, I will implement the missing code soon, so it's just a placeholder atm. We bneed commons coding rules because I used new RuntimeException(not implemented) We certainly need to define a common set of exceptions we should use at Mina. MinaException. We should also discuss if we want them to be runtime or checked exceptions. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [Mina 3] exceptions was Re: [MINA 3] IoBuffer
On Mon, Nov 28, 2011 at 10:05 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/28/11 9:43 AM, Julien Vermillard wrote: On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/27/11 10:18 PM, Christian Schwarz wrote: ...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). Right ! Btw, I will implement the missing code soon, so it's just a placeholder atm. We bneed commons coding rules because I used new RuntimeException(not implemented) We certainly need to define a common set of exceptions we should use at Mina. MinaException. We should also discuss if we want them to be runtime or checked exceptions. On the check/runtime : checked are usual error which should be handled by the API user : a decoding error because the client is sending craps runtime are for bug or problem the API can't do much, he just want to log the error : NPE, socket exceptions, not implemented exception Julien
Re: [Mina 3] exceptions was Re: [MINA 3] IoBuffer
On 28 November 2011 09:38, Julien Vermillard jvermill...@gmail.com wrote: On Mon, Nov 28, 2011 at 10:05 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/28/11 9:43 AM, Julien Vermillard wrote: On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/27/11 10:18 PM, Christian Schwarz wrote: ...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). Right ! Btw, I will implement the missing code soon, so it's just a placeholder atm. We bneed commons coding rules because I used new RuntimeException(not implemented) We certainly need to define a common set of exceptions we should use at Mina. MinaException. We should also discuss if we want them to be runtime or checked exceptions. On the check/runtime : checked are usual error which should be handled by the API user : a decoding error because the client is sending craps +1 Generally used for recoverable conditions. runtime are for bug or problem the API can't do much, he just want to log the error : NPE, socket exceptions, not implemented exception Not sure about socket exception - that may be transient, e.g. temporary lack of resources Also, please use standard Exceptions for standard errors rather than creating subclasses of existing ones. Sometimes it is necessary to create new Exceptions/Errors, but that should be the exception (!). Julien
Re: [MINA 3] IoBuffer
On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny elecha...@gmail.comwrote: Hi guys, Hi Emmanuel, Feel free to comment... ...here we go! Using the 2 MINA IoBuffer is difficult for us because the documentation of it is too hard to reach. JavaDoc's like @see # xy ByteBuffer (..) only makes sense if the IDE displays the linked API docu immediately, otherwise it's far from fun. I think the most of us don't like to lookup the ByteBuffer docu, we want it first hand! We look into the JavaDoc because we need it, just in this moment. So what is more expressive: /** * @see Buffer#hasRemaining() */ vs. /** * Tells whether there are any elements between the current position and the limit. * * @returns true if, and only if, there is at least one element remaining in this buffer */ WDYT? Best regards Christian
Re: [MINA 3] IoBuffer
...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). On Sun, Nov 27, 2011 at 10:05 PM, Christian Schwarz chriss@googlemail.com wrote: On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny elecha...@gmail.comwrote: Hi guys, Hi Emmanuel, Feel free to comment... ...here we go! Using the 2 MINA IoBuffer is difficult for us because the documentation of it is too hard to reach. JavaDoc's like @see # xy ByteBuffer (..) only makes sense if the IDE displays the linked API docu immediately, otherwise it's far from fun. I think the most of us don't like to lookup the ByteBuffer docu, we want it first hand! We look into the JavaDoc because we need it, just in this moment. So what is more expressive: /** * @see Buffer#hasRemaining() */ vs. /** * Tells whether there are any elements between the current position and the limit. * * @returns true if, and only if, there is at least one element remaining in this buffer */ WDYT? Best regards Christian
Re: [MINA 3] IoBuffer
On 11/27/11 10:05 PM, Christian Schwarz wrote: On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharnyelecha...@gmail.comwrote: Hi guys, Hi Emmanuel, Feel free to comment... ...here we go! Using the 2 MINA IoBuffer is difficult for us because the documentation of it is too hard to reach. JavaDoc's like @see # xy ByteBuffer (..) only makes sense if the IDE displays the linked API docu immediately, otherwise it's far from fun. I think the most of us don't like to lookup the ByteBuffer docu, we want it first hand! We look into the JavaDoc because we need it, just in this moment. So what is more expressive: /** * @see Buffer#hasRemaining() */ vs. /** * Tells whether there are any elements between the current position and the limit. * * @returns true if, and only if, there is at least one element remaining in this buffer */ WDYT? I agree. What made me use the @see tag is that it was fast and easy. I do think that it would be better to include some documentation associated to this @see tag. The main issue is that we *must* not copy the original doco (which is copyaighted). -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] IoBuffer
On 11/27/11 10:18 PM, Christian Schwarz wrote: ...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). Right ! Btw, I will implement the missing code soon, so it's just a placeholder atm. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
