#9 Define some well known exception reasons

Petr Kuzel

I would introduce a field to SAXParseException that
would identify which XML rule was broken.

public int getWFC();

The values could be described using an interface.

public interface WFCConstants {
public static final int UNIQUE_ATTRIBUTE_NAME_WFC;

Similarly for VC.
It would allow to improve error reporting. Application
would know reason and may give a hint to user. Current
getMessage() can be just diplayed, it does not allow
application to do a decision except displaing or
hidding it.


  • Anonymous - 2001-12-06
    • status: open --> open-accepted
  • Anonymous - 2001-12-06

    Logged In: YES

    The current plan is to add a new method to
    SAXParseException, perhaps for SAX 2.1 (it's
    an API change) which would include URIs that
    would be used to identify the standard failure

    Rather than defining an interface with numeric
    error codes, the URIs would be defined in some
    document. There would be at least four categories
    (current thought) of URI, all defined with reference
    to specifications such as (initially) XML 1.0 or
    the namespace REC:

    - Violations of well formedness constraints.
    Many of these have IDs in the XML REC, and
    links to those might be used directly.

    - Violations of validity constraints. Likewise.

    - Violations of specific grammatical constructs.
    The complication here is that a given construct
    might be construed as violating any of several
    different construct, for several reasons.

    - Breaking of other rules in the XML spec, where
    an error or fatal error is specified. Not all
    of those cases have link targets defined in the
    XML REC, so some other scheme to define URLs
    might be necessary.

    That's just the current thought on how a new
    SAXParseException.getExceptionId() might work.
    It'd need to handle namespace constraints (one
    more category, sort of like VCs) and maybe more.

    Subject to change, of course. And the hardest
    part will be getting parsers to support it.

  • Anonymous - 2002-03-05
    • milestone: --> Next_Release_(example)
    • priority: 5 --> 6
  • Anonymous - 2002-04-22

    Logged In: YES

    Just checked in to CVS. SAXParseException now exposes a
    write-once exception ID, and the package documentation
    includes the rules for how those IDs get generated.

    NOTE: done as a pure attribute, since it'd be evil to
    double the number of constructors here.

    Now the fun begins: let's get some implementations!!

  • Anonymous - 2002-04-22
    • status: open-accepted --> closed-fixed

Log in to post a comment.