Re: [Babeldoc-devel] PipelineStageFactory

[Bruce M. <br...@mc...>]

Dejan,

The release, all things being equal will go out on May 2 2003

regards,
Bruce.

On Tuesday 22 April 2003 10:56 am, Dejan Krsmanovic wrote:
> This is not good idea. There are places where exceptions should be logged
> without rethrowing them. If I understood you, using your aproach would
> break processing whenever exception is logged. There are situations (like
> project that I am working on) where pipeline stage order depends on error
> that occured. In case of error, I need to send e-mail or something else,
> but breaking processing would not be good for me. Anyway, there are really
> no many places where exceptions should be rethrown. getPipelineStage and
> trackDocument are good examples of methods that should rethrow exception...
> I think it would not be to hard to identify all or most of these methods.
> Also, I don't think it is too important if 1.0 release would be delayed few
> weeks... Bruce when did you planned it, anyway?
>
> Dejan
>
>
>   ----- Original Message -----
>   From: ek...@ba...
>   To: bab...@li...
>   Sent: Tuesday, April 22, 2003 4:47 PM
>   Subject: Re: [Babeldoc-devel] PipelineStageFactory
>
>
>
>   <<
>   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.