[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages

Daniel Weinreb wrote:
> So what you're telling me is that if you are reading a program, and the
> program calls entrypoint X, and you don't know the API (the contract)
> for X, then you might have trouble understanding the program.  Well, gee,
> that would be true even if there were no exceptions at all!  Of course
> you have to understand the contract of the entrypoint you call!

The difference is that in all other respects, the contract does not involve
screwing with the caller's control flow.  It simply involves values provided
and received - an encapsulated communication.

It's like phoning your friend from your living room and finding that he's
somehow moved you to the bathroom... :)

Something that could help this in Java, given its static typing, would be if
IDEs highlighted lines that throw exceptions.  Perhaps you've memorized
every API in J2EE - I have to confess I'm not there yet, nor would I ever
want to be.

I want to be clear about something: I'm not saying the whole notion of
exceptions and the try/catch structure is bad, only that currently it's
rather primitive and unsophisticated, and that it creates problems as well
as solving some.

> At eXcelon on the BPM project

The BPM project sounds impressive.  I work on BPM systems myself, and Java
is one of the primary languages we use.  We use exceptions, of course, and
some of what I'm talking about comes from experience in that environment.
As we've previously discussed here, we also use tricks like anonymous inner
classes to wrap exception-throwing code and handle logging.  But these are
workarounds for the situation I described, which I'll repeat in edited form:

> I think the exception systems in languages like Java and C++
> are horribly primitive. They do address an important issue,
> but they do so in the most minimal and invasive way possible.

Your response to the original version of this was:

> Needless to say I totally disagree.  If I had to program in Java without
> the exception system, life would be far worse than with the exception
> system.

I wasn't actually suggesting coding without the exception system, in the
kinds of applications for which Java is used.  But I do think the exception
system could be improved, and you agree:

> Life would be better if the Java exception system embodied
> more of the stuff that's in the coding standards that Rowley and I

Yes, many of the flaws I'm talking about can be addressed by coding
standards.  They could be addressed even better by improvements in the
language itself, as you suggest:

> In fact they have made one step in that direction in Java 1.4, adding
> the "cause" (or whatever it's called) instance variable, which we were
> doing as part of our conventions.

This kind of thing is exactly where my characterization of exception support
as "minimal" comes from.  It's amazing it's taken so long for something as
simple as this to get into the JDK.  Let's discuss this again in 10 years
time - looking back on exception handling today, we'll wonder how people
managed to get anything done.  Current exception systems are not going to be
the solution to the allegedly dismal state of software today.  They might be
an improvement in some senses, but if you're happy with them as they stand,
your standards may be too low.

> Do you divide the world into two classes, "mission critical" and "it
> make no difference whether there are gobs of bugs"?

It's possible to write reliable code without explicit Java-like exceptions.
In that kind of code, many kinds of error can legitimately, and implicitly,
be ignored.  There are pros and cons to that.

I also think it's possible to go overboard in one's insistence on perfect
systems.  Worse is better, yada yada.  There's a strong economic incentive
to develop things that are only barely good enough, and that's more of a
driver of the state of software than anything technical.

It sounds to me as though your bad experiences with other people's scripts
have led you to believe that the imposition of mandatory exception handling
would be the solution.  That would make more sense to me if better exception
handling systems existed.  As usual in these discussions, we're discussing
opposite extremes: the Java situation where all possible exceptions have to
be explicitly managed or passed on by the caller, vs. the error-code
situation where checking exceptions is completely optional.

Richer systems are certainly possible, e.g. systems with more centralized,
declarative exception handling strategies, so that I can identify sets of
exceptions that I don't care about in certain situations, for example, and
then in those situations, simply identify the exception handling strategy I
want.  Some of this might be hacked in Java using inner classes and some
kind of exception profile class, perhaps.  But that still proves my point:
current systems leave a lot to be desired - and in addition, I don't see a
lot of attention being paid to it.

If you really care about the current state of software, you should join my
side!  Better exception systems for all!!  ;)