RE: Introspect whether setCharacterEncoding is present..

> Next week I'm going to be taking up my post as Donald Rumsfeld's plain
> speaking coach.

Cool! I think he could use you :)

> > No one said anything about non-local exits.

> Err... I did. 
 
Exactly!
 
> Several times. They are a major reason for using
> Exceptions other than error handling. They give the lie to the
> statement that you must not use Exceptions for control flow.

Well there _is_ an exception (pun intended) to every rule...

> > The point is that using Exceptions for Critical Paths is not such a
> > good idea.

> As I said. This is nonsense. 
 
Note, I said not a good idea, not that you should never do it.
 
> If your code happens to be a large FSM
> then you are going to need non-local exits in the "Critical Paths" in
> your code. This is the only way to make such code readable, the only
> other way to write it is as one large method. And that isn't a good
> idea (also you might need the method call stack anyway).
 
I would still look for other "elegant" ways to do it before falling down to using Exceptions. Using Exceptions being the easy way out, tends to also become the most difficult to maintain implementation. Again, this is _generally_ true, and there definitely are exceptions (pun not intended this time).

> What is a critical path anyway? 
 
(Finally a chance to show off my UP training...) A critical path, is what you call a "Main Scenario" in a use case.
 
> Which bits of my program can I leave
> out because they're not critical? Grrrr...

I hear you.

> > They make your code harder to read.

> No they don't. They CAN make your code harder to read.
 
I agree with you, Nic. But not every programmer is as smart as you. (No, I'm not pulling your leg here. Honest.)
 
> But if you didn't use them in some situations then your code would be
> much harder to read than the other possibilities.

Couldn't agree with you more. But it's better to make the suggestion to not do something, and let the smart ones figure out where to break the rules, than to suggest the opposite, and have only the smart ones know when to follow the rule. (I'm sure I could draw out an analogy involving Critical and non-critica paths, but I'm feeling a bit sleepy)
This bit of advice comes from having taught peope how to write code, and seeing the results. Or maybe I've just had some bad students.
 
> And do you really think that Charles' example was hard?

No. But show this kind of code to someone, tell them it's the right way to do something, and they're going to end up replacing "DoSomething()" with a 40 line code block that is going to cause the person supporting it, to tear his (or her) hair out in frustration, trying to figure out which of those lines causes the exception.
 
> I don't. I've managed lots of code like this written by other
> people. I also write and manage it myself.
 
And I've had the misfortune of having to look at the other end of the spectrum.

> All I'm saying is that there is an application for Exceptions other
> than errors. You CAN use Exceptions for non-local exits and they are
> not expensive. Of course, you have to take care. But you should take
> care about the way you right programs anyway.

No arguments there.

> These are:
> - multi method FSMs
> - predicating behaviour on assertion by Exception

You got me on the last one. Hadn't thought about that.

> But perhaps you mean it's not
> preferential but we have to do it.

Exactly.

> > Yes, but was the example that triggered this entire debate one of
> > those? Admitted, it's the only obvious way to check if the class
> > exists in the current JVM, but Class.forName() is really intended to
> > get an instance of a class if you expect it to be there, and not as
> > a mechanism to check if the class exists.

> The only obvious way? Or the only way?

I refuse to believe that there isn't a really really hard, ass-brained (mind my language) way to do it without using Exceptions - like writing your own Class Loader. Maybe I'll try my hand at it this weekend. (Before you say that I'd be crazy to use that kind of solution over using Exceptions, let me point out that I'm too lazy to do that)

> > The fact that the Java standard API doesn't give you a better way to
> > check for the existence of a class without throwing an exception (it
> > doesn't, right? Just checking.) does NOT make the suggested way, The
> > _Right_ Way. It just makes it a convenient hack to get around the
> > limitations of the existing API - also known as, The Only Way.

> It's not a cruddy way to do it: it's THE way to do it.
> What are we to do when writing programs?
> Not do something because it's inelegant?

Maybe I wasn't clear. Maybe something _is_ the only way. But it may still be inelegant. And I may do it. But I don't have to like it.

> Inelegant and inadvisable are different things.

Agreed.

> Non-local exits got included in this thread because the suggestion was
> made that Exceptions should not be used for control flow. Non-local
> exits were an obvious and legitimate use for Exceptions that made the
> suggestion a lie.

Incorrect. Non-local exits don't make it a lie. They only show you the exception to that rule.

> Actually I do a bit of that from time to time. I'm a hacker. People
> hire me to sort stuff out. I have to read people's code and manage it
> all the time. And I find that reading the code rather than the log
> statements is the most sensible tactic.
 
Right. But sometimes there's external API that does stuff, that you don't have access to the source-code for. (Let's not start another "that's why open source is a good thing" debate here. I'll agree with you anyway). In those cases, you just _have_ to look at logs.

> There really is nothing wrong with goto, Sun call it continue or break
> and they use it quite often in JDK code I'm told.

And I hate 'break' and 'continue' more than I don't like 'goto'. They're like the black sheep in the family dressed in cotton candy.
The people working at Sun aren't necessarily the smartest Java coders in the world. Remember java.util.Stack?

> > And as far as the performance aspect goes, I don't disagree with Nic
> > there. Most times, the effect of throwing Exceptions, on
> > performance, is negligible.

> Good man.

See Nic? I'm really on your side.

> The only other way I can see of doing Charles' code is this:
>
>   boolean exists = false;
>   try
>   {
>     Class.forName("com.bull.LoadOf");
>     exists = true;
>   }
>  catch (...Exception e)
>  {}
>
>  if (exists)
>  ...;

Yuck.

> I prefer Charles' way because there is something in the catch
> handler. Empty catch handler's are bad IMHO (and yes, there are *real*
> reasons why that is so).

No arguments there.

> The reason I'm being so pugnacious about this is three fold:

> 1. I believe that it is dishonest to impose stylistic restrictions on
>    use of computer languages

And dishonest can be good if it keeps 90% of bad programmers in line 80% of the time, because good programmers would figure out the right way themselves anyway.

> 2. I find it patronizing when people suggest that certain things make
>    programs too difficult for support people or newbies or old people
>   or people with glasses or short people or whatever
 
Until, of course, you have one of these guys trying to fix your application.

> 3. I've been implementing Scheme recently in GNU C and continuations
>    are really cool and make you appreciate the whole role of the
>   stack.

Hmmm. Care to write a paper about it?
 
RJA


[Non-text portions of this message have been removed]



------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~-> 

Before posting a question, try to find your answer here: 
<http://www.egroups.com/links/advanced-servlets>
Announcements should go to: [email protected]
To Post a message, send it to: [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/advanced-servlets/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/