[Jakarta HiveMind Wiki] New: CentralizedErrorReportingProposal

[hi...@jakarta.apache.org]

   Date: 2004-06-05T06:49:50
   Editor: HowardLewisShip <hl...@apache.org>
   Wiki: Jakarta HiveMind Wiki
   Page: CentralizedErrorReportingProposal
   URL: http://wiki.apache.org/jakarta-hivemind/CentralizedErrorReportingProposal

   no comment

New Page:

= Problem Description =

HowardLewisShip, Jun 5 2004, 1.0-alpha-5

Some discussion has been going around about how !HiveMind reports errors (errors when parsing deployment descriptors, and errors at runtime).

I prefer a ''lenient'' system, where early errors are reported and then the system continues on as best it can (with the expectation that early errors will blossum into later failures).

Others prefer a ''strict'' system, where early errors result in thrown exceptions and, potentially, no Registry or a shutdown of the application entirely.

Tapestry has traditionally used a strict system and, to date, !HiveMind has used a lenient system.

This proposal is to make this ''strategy'' pluggable, so that it can be controlled by individual developer's taste and situation.  It may also help Geoff (or whoever) writes an Eclipse plugin.

= Proposed Solution =

Part of the solution is already in place: {{{org.apache.hivemind.impl.ErrorHandler}}} is used by the module deployment descriptor parser; the default implementation is lenient but a strict implementation can be provided.

This interface should be moved to package {{{org.apache.hivemind}}} and should be extended:

{{{
public interface ErrorHandler
{
  public void parseError(Log log, String message, Location location, Throwable cause);

  public void error(Log log, String message, Location location, Throwable cause);
}
}}}

I think it is important to separate errors that are directly related to module descriptor parse problems from runtime errors.  So an unexpected element in a descriptor might be a {{{parseError()}}} but an invalid class name would be an {{{error()}}}.

  * Do we need more methods?

The default behavior would be to use the {{{Log}}} instance to log the error, as:

{{{
Error at <location>: <message>
}}}

or

{{{
Error: <message>
}}}

Depending on whether {{{location}}} is null or not.  The exception would be provided (if not null).

== Obtaining the ErrorHandler ==

The Module and !RegistryInternal interfaces will be extended to provide access to the !ErrorHandler.  Possibly, they will implement the !ErrorHandler interface and delegate out to a user-provided instance.

== Providing the ErrorHandler ==

The !ErrorHandler will be provided to !RegistryBuilder, which will use it when parsing module descriptors and provide it to the Registry as it is constructed.

== Changes to error messages ==

Because the location will be uniformly displayed, it will not be necessary to include the location in error messages, which (I think) will make many of the existing error messages more readable. It will also make the messages more palatable to, for example, an Eclipse plugin (which will have other means of identifying the location of the error, rather than emedding that location as text within the message).  Locations will be part of error messages only when discussion ''two'' locations, such as when an interceptor is contributed more than once to a service point.


= Discussion =


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org