RE: [Htmlparser-developer] HTMLParserFeedback issues..

[Somik R. <so...@ya...>]

--- Claude Duguay <CD...@ar...> wrote:
> Some errors are non-fatal. In our (Arcessa's)
> application, for example, a parser error means that
> the document could not be handled and needs to be
> logged, but the application moves on to the next
> document without stopping. Within the parser, the
> question is more granular. There may not be any case
> where you don't want to abort when you have an
> error. You can still report the error AND throw an
> exception. Think of feedback as a mechanism for
> logging that may be ignored or redirected at the
> user's discression. It's a hook that lets developers
> redirect the output so that it doesn't go to the
> console. Although the default feedback goes to the
> console, developers are not tied to that behavior
> and you have a way of making sure nothing is left
> unreported.

I get it. The next question though is - what sort of
performance hit are we looking at ? There are creation
of strings - and even if we replace the default
feedback with another that does not display- there
would still be an overhead, right ? Or can intelligent
compilers figure out calls to empty methods and hence
do optimizations there ?

Regards,
Somik

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com