[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Seeking SAXException pattern

• To: Tim Bray <tbray@t...>
• Subject: Re: Seeking SAXException pattern
• From: Paul R Brown <prb@f...>
• Date: Sat, 27 Nov 2004 18:37:15 -0600
• Cc: xml-dev@l...
• In-reply-to: <D369065E-40D3-11D9-BB2B-000A95A51C9E@t...>
• References: <D369065E-40D3-11D9-BB2B-000A95A51C9E@t...>

Hi, Tim --

> I'm writing some java code that uses a basic SAX parser, and I haven't 
> done this for years if ever, and the callback routines all have 
> signatures that throw SAXExceptions, [...]

1) For what you describe, subclassing on SAXException or on 
SAXParseException (which already extends SAXException) is the way to 
go.  Choose SAXParseException if you want to include locator 
information in a format that a downstream client will know how to 
access.  In the code that calls xmlreader.parse(), you can use a catch 
MySAXExceptionSubclass to see if the exception was one of yours.

2) You could also equip your handler with an ErrorHandler and report 
through that interface as opposed to throwing exceptions, allowing the 
ErrorHandler implementation to throw an exception when appropriate 
(e.g., on a "fatal" error).  (Subclassing on SAXParseException can be 
useful here, but the assumption would be that the ErrorHandler 
implementation wouldn't necessarily be yours.)

#2 makes more sense for validation or informational use cases.

My $0.02.

	-- Paul

• References:
  • Seeking SAXException pattern
    • From: Tim Bray <tbray@t...>

• Prev by Date: Seeking SAXException pattern
• Next by Date: Re: Re: licensing ... [Re: binary XML API and scientificuse cases [Re: [ANN] nux-1.0beta2 release
• Previous by thread: Seeking SAXException pattern
• Next by thread: Re: Seeking SAXException pattern
• Index(es):
  • Date
  • Thread