That could be done, but if its not a complete solution, then I'm not sure it
ends up really being any better than it is now, since there is still the
possibility of getting both types of errors and you have to be prepared to
do so.
--------------
Dean Roddey
Software Geek Extraordinaire
Portal, Inc
[EMAIL PROTECTED]
-----Original Message-----
From: Dee Jay Randall [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 10:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Parse Exceptions vs. fatal errors
Not that I know what I'm talking about, but would it make
sense to have the parser catch all exception ids and rethrow
the ones it doesn't understand? Then if you wrote your own
input source, you would at least benefit from the exception ids
that the parser could understand (and you wouldn't have to write
a lot of code duplicated in the parser). And in the case of ids
beyond what the parser could handle, they would get rethrown anyway.
Just my thoughts.
Dee Jay
+-----------------------------+------------------+-----------------------+
| Founding Partner | Software Engineer| Dee Jay Randall, B.Sc.|
| Circular Reasoning | Accrue Software | M.Sc. Student, CS |
| [EMAIL PROTECTED]| www.accrue.com | ICQ # 43551676 |
+-----------------------------+------------------+-----------------------+
What is the average rank of every song ever written? 42 -- www.launch.com
On Tue, May 29 2001 at 06:39:51P -0700, Dean Roddey wrote:
> The only time an XML exception is exposed is if something goes very wrong
> during the very early stages of starting a parse, so that it couldn't even
> figure out what its trying to open. Once it gets that far, everything else
> should come out as errors via the error handler. You can get exceptions if
> you use input sources because they might do some prep work on their own
when
> the parser starts to use it, and fail in the process of getting themselves
> together (such as trying to create the full path in the case at hand
here.)
> This could probably be moved inside the internal exception handler as
well,
> but there will always be the possibility that something can go wrong such
> that the parser cannot catch it internally, since it could be something
that
> happens in an implicit conversion on a parameter to a call into the
parser.
>
> Another issue with input sources is that you can write your own. The
parser
> can only deal with error codes it defines. If you write your own input
> source, and it throws ids that the parser doesn't understand, its not
going
> to know what to do, so it might be best to keep those things outside of
the
> parser's try/catch.
>
> --------------------------
> Dean Roddey
> The CIDLib C++ Frameworks
> Charmed Quark Software
> [EMAIL PROTECTED]
> http://www.charmedquark.com
>
> "Why put off until tomorrow what you can
> put off until the day after tomorrow?"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
