#9 Define some well known exception reasons

closed-fixed
nobody
6
2002-04-22
2001-11-27
Petr Kuzel
No

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;
int EBNF_SYNTAX_ERROR_WFC;
int LT_IN_ATTRIBUTE_VALUE_WFC;
int LEGAL_CHARACTER_WFC;
int ENTITY_DECLARED_WFC;
etc.
}

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.

Discussion

  • David Brownell
    David Brownell
    2001-12-06

    • status: open --> open-accepted
     
  • David Brownell
    David Brownell
    2001-12-06

    Logged In: YES
    user_id=44117

    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
    modes.

    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.

     
  • David Brownell
    David Brownell
    2002-03-05

    • milestone: --> Next_Release_(example)
    • priority: 5 --> 6
     
  • David Brownell
    David Brownell
    2002-04-22

    Logged In: YES
    user_id=44117

    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!!

     
  • David Brownell
    David Brownell
    2002-04-22

    • status: open-accepted --> closed-fixed