Re: [Jsdsi-devel] CertStore Branch

[Sean R. <sra...@ae...>]

Sameer Ajmani wrote:

>>I haven't changed JsdsiCertStoreException to be checked... I thought we
>>had agreed back April time to use RuntimeExceptions. I've gone more and
>>more off Checked Exceptions. Have a read here for other (well known
>>peoples' views):
>>
>>http://www.artima.com/intv/handcuffs.html
>>http://www.mindview.net/Etc/Discussions/CheckedExceptions
>>    
>>
>
>These are interesting arguments, but I don't actually think JSDSI has
>the scalability and versioning problems described herein.  This is
>because by having a top-level JsdsiException and other exceptions that
>derive from this, clients can just catch that exception as they would
>a runtime exception (they could even wrap it in a runtime exception if
>they really prefer that).  So even if we have JsdsiProverException,
>JsdsiSignatureException, JsdsiCertStoreException, etc, the caller can
>just catch an dprocess JsdsiException, or pass it along, or re-throw
>something else.  But making it checked guaranteed the compiler will
>give clients of JSDSI a heads-up that there's an exception that may be
>thrown.
>
>btw, I'm a big fan of exception chaining, so I definitely think any
>Java Crypto Exceptions should be wrapped in a JsdsiException subclass;
>users who care about the distinction between NoSuchProviderException
>and NoSuchAlgorithmException can follow the causal chain to find this
>information.
>  
>
Ok, I'm for that.

Would you like me to (in the certstore branch):

1. Ditch JsdsiRuntimeException
2. Create a JsdsiException (a checked exception)
3. Refactor other code to throw a JsdsiException (or a subclass).

I would also vote to clean-up the cerstore branch, in terms of removing 
a number of the deprecated methods, then merge into HEAD and make a 
shiny new release to sf.net. Thoughts?

>  
>
>>>In JdbcCertificateDAO.retrieve(), extract the long if-else chain into
>>>a method that does:
>>>return retrieve.(...);
>>>- in each if-branch.  This makes the code easier to read, since it's
>>>clear "result" is only assigned to once in retrieve().
>>>
>>>      
>>>
>>Sorry, but not sure I understand what you mean by this. If you mean to
>>not assign to 'result' but just return, then you loose the logging
>>information.
>>    
>>
>
>Actually, I just meant to move the if-then-else to a method, so as to
>guarantee result is never accidentally left as null.  Again, this is a
>way to let the compiler help you: if the if-then-else is in a method,
>and each branch returns the result, then the compiler will complain if
>not all cases are covered.  You would still have your roriginal method
>assign the returned value to a "result" variable, log it, and return
>it.
>
>  
>
Understand. Will do.


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com/