Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
>
>>>I also question that it results in more performant code, as you
>>>do not pay for exceptions unless they are thrown (See
>>>http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
>>>for exception handling.)
>>
>>so I thought originally. Stefano suggested differently though. Stefano?
>
>
> No, this is correct. Exceptions-wrapped lookups irritate me for the
> performance penalty
Premature optimization is the root of all evil.
> of lookup failure *and* for the verbosity penalty in
> code.
get, set, ...
Wanna use lisp?
Java *is* verbose, but it's part of the semantics in this case.
> For example, try/catch was designed to allow more stuff to be included
> in a single try/catch, this covers for many different errors of the same
> kind. So
>
> try {
> ... [a bunch of code] ...
> } catch (A a) {
> ...
> } catch (B b) {
> ...
> } catch (C c) {
> ...
> } catch (D c) {
> ...
> } finally {
> ...
> }
>
> this is a declarative way to associate specific behavior on the errors
> that emerge on a code that is *assumed* to work correctly.
>
> In Avalon, the granularity of the exception is too low, forcing you to
> have a single try/catch on every component, in order to provide
> meaningful error messages. Sure, you could do:
>
> try {
> ...[ a bunch of lookups ]...
> } catch (ComponentNotFoundException e) {
> ...
> }
>
> but the error message
>
> Sorry, can't find a component.
>
> will irritate me even more. (note that the exception originating line is
> lost on stacktrace exceptions (which is a big design mistake for java,
> IMO)).
Which we should take care to avoid, of course, properly cascading.
> So you do
>
> try {
> parser = (Parser) cm.lookup(Parser.ROLE);
> } catch (ComponentNotFoundException e) {
> log("can't find parser");
> }
>
> and so on. If you look in Cocoon we have several hundreds of examples of
> this. Now, with exists, you can do:
>
> if (cm.exists(parser)) parser = (Parser) cm.lookup(Parser.ROLE)
> else log ("can't find parser);
>
> which could be equally verbose if written like
>
> if (cm.exists(parser)) {
> parser = (Parser) cm.lookup(Parser.ROLE);
> } else {
> log ("can't find parser");
> }
>
> but the difference is that if I'm *POSITIVE* that the component already
> exists (otherwise, I couldn't possibly reach this point in code! we have
> tons of examples of this in Cocoon), I don't care and go directly on
>
> parser = (Parser) cm.lookup(parser);
>
> Now, if we make 'ComponentNotFoundException' extend RunTimeException,
> then we could be back-compatible with the try/catch style failure, but
> without *FORCING* people to do it, if they don't want and know what they
> are doing.
If people would always know what they are doing, we would have pointer
arithmetic in Java.
The point is, believe me, that in some things, see exception handling
and build systems, programmers simply don't care much.
As Avalon forces, or at leat tries to force, IoC with interfaces and
lifecycle, we should not run away from doing it with exceptions.
You have SoC bells ringing, I have my exception handling bells going
WILD now :-O ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
