Re: [Babeldoc-devel] PipelineStageFactory

[<ek...@ba...>]

<<
No, dont fork the codebase, let the exceptions move up the stack - just 
make
sure that they get caught "somewhere".  The "somewhere" in the case of
PipelineFeeder.process is ultimately called from PipelineFeeder.execute. 
In
this case all the possible exceptions are caught so all is well.
>>

My suggestion was either for me to modify the codebase or for ME to break 
away from the codebase and develop independently.  I had no intention of 
forking the codebase within CVS (if that is what you meant).

As to catching the exception "somewhere", I personally feel that the 
system should expose certain "high-level / client-consumable" exceptions 
through its entry points.  Otherwise, clients of this software (even 
command-line processes) will not be aware of the errors occurring within 
Babeldoc and can code to handle them.  I am certainly no expert at the 
exceptions being used in the software, but it seems to me that exceptions 
such as PipelineException and JournalException seem "client consumable".

My approach would be the following:
1. Search out areas where exceptions are being discarded or just logged
2. Choose an "appropriate" exception class to represent the exception and 
include this in the "throws" clause of the method signature.
3. Allow the compiler to identify all the calling methods which either 
need to also "throw" these exceptions or take specific action to "trap and 
handle" the exception

I just finished a quick analysis that identified every "catch" statement 
in the entire codebase.  Following are some statistics:
-- 289 catch statements
        -- 157 of these either log the error or do printStackTrace ... 
discarded
        -- 33 of these do nothing ... discarded
        -- 99 of these rethrow the exception "appropriately" ... handled

Not included in the numbers above are situations that obviously require no 
exception handling (inability to close a database prepared statement / 
connection, code that specifically documents that nothing should be done). 
 It should be noted that most of the Scanner, PipelineStage, and Journal 
classes do a very good job of exception handling.

Please provide your thoughts on the following suggestion:
Since there are many places that simply log the error (using the 
commons-logger), one "quick and dirty" approach would be to have the 
underlying logging system throw a type of RuntimeException after the 
logging has occurred when a logError request is made.  This would mean 
that no method signatures would need to be modified and exceptions would 
flow straight to the top of the call stack.  It would require very little 
effort and would allow us to be one step closer to v1.0, but would not be 
"as professional".  Maybe this is a good stop-gap solution until 1.0 is 
released.

What are your thoughts?

Erik

________________________________________________________________________
The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses.