Re: [Babeldoc-devel] PipelineStageFactory

[Dejan K. <dej...@nb...>]

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.=20
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 -----=20
  From: ek...@ba...=20
  To: bab...@li...=20
  Sent: Tuesday, April 22, 2003 4:47 PM
  Subject: Re: [Babeldoc-devel] PipelineStageFactory



  <<=20
  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.
  >>=20

  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).=20

  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".=20

  My approach would be the following:=20
  1. Search out areas where exceptions are being discarded or just =
logged=20
  2. Choose an "appropriate" exception class to represent the exception =
and include this in the "throws" clause of the method signature.=20
  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=20

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

  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.=20

  Please provide your thoughts on the following suggestion:=20
  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.=20

  What are your thoughts?=20

  Erik=20
  =
________________________________________________________________________
  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.