hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] New: CentralizedErrorReportingProposal
Date Sat, 05 Jun 2004 13:49:50 GMT
   Date: 2004-06-05T06:49:50
   Editor: HowardLewisShip <hlship@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


Mime
View raw message