L
Lew
A) this does use a logger, and B) the purpose isn't to show logging but chaining.
If you think I was "just trying to log all causes" then you missed the point.
A) this does use a logger, and B) the purpose isn't to show logging but chaining.
If you think I was "just trying to log all causes" then you missed the point.
P
Pitch
Well, if you use Logger implemetation form Apache.org, this does exactly
what you code does (but in fewer lines):
log.error(this, null, trow);
So you say inheritance is not the way to go? We should look through the
chained-exceptions to find out if we need to handle a general exception
or not? Doesn't that clutter the code with loops and if-statements?
point.
Well, why don't you explain if you think I misunderstood something? Or
is it that you think your time is too valuable for a simple explanation?
Anyway I think you're completely wrong and I wouldn't suggest to anyone
to use this approach.
L
Lew
Exactly what I coded? It uses getLocalizedMessage() and does not
display a stack trace? For all logging libraries? Are you quite
sure?
Lew:
I said it was an alternative, and quite a useful one when the
exceptions are not hierarchically related. In general one cannot
ensure that all exceptions are hierarchically related, and when one
wraps and rethrows with a lower-level exception as a cause, chaining
is the only way to go.
Lew:
It was explained in my post to which you originally replied.
I said:
Clearly from that you can see that my point was about chained
exceptions, no?
Stow your sarcasm; it was you who missed the point, not I who failed
to explain it.
Too bad for the people you're advising, then. Exception chaining is a
very powerful tool and quite usually the only way to get at root
causes, and it's quite standard throughout the Java universe/
A
alexandre_paterson
If you're interesting in some controversial reading or discussions...
It should be noted that there are a lot of Real World [TM]
applications powering, well, pretty much the entire
Real World [TM] that are developed in languages that do not
have the SNAFU concept of checked/unchecked exceptions.
The almighty Joshua Bloch has quite a lot to say on checked
exceptions. For a start, "prefer state testing methods to
checked exceptions".
Lots of food for thoughts in that advice and, of course,
that's how things are done in languages that do not have
the concept of checked exceptions.
If you're interested in views that are unlikely to be
found entertaining in this group, a lot of people consider
checked exception to be GOTO programming.
As an example, we're working on a medium sized codebase
(it's not the Eclipse codebase but it's not either dad & mom's
petstore app) here: a client/server app whose client app
is deployed daily on hundreds of new machines.
The client side app is mostly Java (about 1% of native code)...
The number of checked exceptions we defined in our codebase?
Zero.
Once again, if GOTO-style checked exceptions were mandatory
to be able to develop applications, how would people coding
in languages not supporting checked exceptions do their work?
Food for thought I tell you:
Joshua Bloch: "Prefer state testing methods to checked exceptions".
Why do we define zero checked exceptions? Well, simply because
they don't exist at the OOA/OOD level.
We provide OO abstractions and we translate our OOA/OOD to
Java using only (Java) interfaces.
'Checked exceptions' represent nothing at that level.
People using them are cornering themselves in some Javaites
details that shouldn't exist.
Result? Impossible to port and GOTO-like spaghetti codebase.
Btw I've also worked for a company that wrote an automated
solution for porting applications to hundreds of mobile
devices. We translated Java to Objective-C code automatically
and have published apps on the Apple appstore that reached
the top ten where we wrote exactly *zero* line of Objective-C
code. It was all automated translation. Having a clean
OOA/OOD and straightforward OOD -> OOP that do not rely on
"Javaites" helped a lot of course
Now there's something else... You're talking about rollbacks
and it screams famous RDBs.
OO and RDB don't mix well: they're mostly orthogonal concepts.
And CRUD sucks big times. The next thing is CRA
People and companing working as Java/SQL plumbers have cornered
themselves in one field of the computer industry, Ted Newards
make a very good writing on the subject that gained quite a lot
of traction:
"Object-Relational mapping is the Vietnam of our industry"
If you're interested in reading and discussions, that's a good one.
Did I mention that in addition to using zero checked exceptions
we're using an OO DB?
So, using broken APIs that forces you to do GOTO-style programming
because they know knowing about neither good practices, nor OO, sure,
sometimes you're forced to because you can't do otherwise.
But then of course you can ditch such crappy APIs and go use
APIs and framework from people who "saw the light".
The Spring dudes, for example, puke on checked exceptions because
they're, well, a Gosling brainfart...
From the Spring doc:
"Again in keeping with Spring's philosophy, the ...Exception that
"can be thrown by any of the ... interface's methods is unchecked"
*is unchecked*
That's the Spring philosophy. That's the way to do it.
80's GOTO programming should be dead (it ain't but it should be).
Spring's doc also states that: "JTA is a cumbersome API to use
(partly due to its exception model)"
Do like us, stand on the shoulder of giants.
Listen to what Joshua Bloch says, read about Spring, read on OO.
Take everything written in c.l.j.p. with a grain of salt because
most posters here tend to consider every Gosling brain fart to be
the holy gospel
P.S: Lew the grammar nazi can go talk to his psychiatrist about
my grammar and spelling mistakes (not native english speaker here)
L
Lew
[email protected] said:
<http://en.wikipedia.org/wiki/Godwin's_law>
Stop being a troll, "Alexandre".
A
Arved Sandstrom
Lew said:
Ahh, give him a break, Lew. He's merely exhibiting youthful enthusiasm,
and an attraction to programming fads born of lack of experience. Right
now it's his anti-SQL, anti-checked exceptions, super-pure OOP phase.
Next year he'll be evangelizing something else.
AHS
L
Lew
Arved said:
I have no problem with the on-topic part of his rant. He raises
interesting questions.
It is perhaps far more instructive to suss out why a wrong opinion is
wrong than why a correct opinion is correct.
It is curious to see exception handling regarded as "GOTO-like" and
somehow anti-object-oriented (object-anti-oriented?), given that the
only places I've seen exceptions are in object-oriented languages like
C++ and Java, and, of course, the OP's darling, Objective-C.
T
Tom Anderson
I am particularly tickled by this idea that 'pure OOP' thing - the idea
that exceptions are Bad and Wrong because they're not in the particular
theoretical model he's arbitrarily latched onto. It could have been so
different if he'd read a different book first!
tom
M
Martin Gregorie
PL/1 used exceptions, wasn't OO and didn't use them on a particularly
GOTO-like way. I thought they were a pain because the trap didn't have to
be closely related to the place(s) there exceptions occurred - they just
had to be in the same block or an outer level something like:
on endfile(infile)
in_ended = '1'b;;
....
....
do until (in_ended)
read file(infile) into(inrec);
....process inrec....
end;
and you needed another, syntactically unrelated, trap to deal with the
exception caused by opening an non-existent file.
A
Arved Sandstrom
Lew said:
Well, there isn't a single feature of any programming language that
doesn't eventually get criticized. Pundits, or wannabe pundits, seek to
create or cement reputations by looking for new things to criticize. So,
on this note, you get dubious creeds like
http://www.joelonsoftware.com/items/2003/10/13.html. Once someone with a
bit of a following issues a fatwa, you'll always have some characters
like Alexandre who parrot it without any understanding of right or
wrong. In fact, based on some of his wording, I'd practically guarantee
that he read that Spolsky article.
AHS
J
Joshua Cranmer
Return values for exception handling? YUCK.
In my view, there are three main ways of handling exceptions:
1. Pass it through to your caller
2. Ignore it
3. Specifically deal with it
Normal exception handling mechanisms tend to prefer #1, return value
mechanisms prefer #2, and checked exceptions prefer #3.
That return value mechanisms tend to promote swallowing errors is the
basis for my disgust.
A
Arne Vajhøj
Pitch said:
That is what he showed.
He just did - see above.
Exception chaining is a very common technique.
Arne
P
Pitch
Well, not exactly, but it's pretty much the same thing. Anyway I don't
see the purpose of your method (related to this topic). And if you
wanted to show chaining it's not necessarry since the original poster
already talked about it.
I'm sorry but I say you posted this code just to show how you can write
cool for-loops.
Ok, you right, but I would add this: if you design is bad, you must use
any helper tools you can get!
And yes, I think this aproach is a product of a badly designed software.
Exception cause should be only referenced as to be able to list it in
the log files, for history/debug purposes, so to say.
According to the Law of Demeter, a class should not access other than
immediate classes.
http://en.wikipedia.org/wiki/Law_of_Demeter
And isn't exception-chinaing just another buzzword for keeping a simple
reference?
I'm gonna skip the rest of our "misunderstandings" conversation.
A
Arved Sandstrom
Pitch wrote:
[ SNIP ]
That's the main use of root cause, yes.
When you're unrolling/unwrapping chained exceptions you're not violating
that law at all. Each access is to an immediate friend. To think that
this process violates the LoD is like thinking that traversing a linked
list violates that law.
I wouldn't call it a buzzword. The core idea is to wrap the original
exception when you rethrow an exception more suitable for a higher
layer, so as not to lose information. Since you can rethrow several
times it's "chaining". If you didn't use the term "chaining" you would
have to invent one, like...ummm...chaining.
AHS
[ SNIP ]
That's the main use of root cause, yes.
When you're unrolling/unwrapping chained exceptions you're not violating
that law at all. Each access is to an immediate friend. To think that
this process violates the LoD is like thinking that traversing a linked
list violates that law.
I wouldn't call it a buzzword. The core idea is to wrap the original
exception when you rethrow an exception more suitable for a higher
layer, so as not to lose information. Since you can rethrow several
times it's "chaining". If you didn't use the term "chaining" you would
have to invent one, like...ummm...chaining.
AHS
P
Pitch
e2 = e.getCause();
e3 = e2.getCause();
e4 = e3.getCause();
I don't think e3 is a friend of _this_ class, and that's what Lew's for-
loop does. It accesess all strangers-intances just to call
getLocalizesMessage() on them.
More apropriate would be to do have something like this:
e.getAllLocalizedMessages()
which will internally and recursively use cause member.
Every article I've found on the topic of chaining exceptions says
nothing else but that there is a nifty way to stash a reference to the
root eception. There is no special usage of that reference. It didn't
even exist before java 1.4, you had to write it on your own!!!
L
Lew
Pitch said:
It must have been considered quite a useful feature to add exception chaining.
You provide evidence here that exception chaining is a good thing.
P
Pitch
The road to hell is paved with good intentions.
L
Lew
Pitch said:The road to hell is paved with good intentions.
Very cogently argued. ;-}
T
Tom Anderson
If i ever start a programming blog, i will totally call it Dubious Creeds.
Or a band.
tom
T
Tom Anderson
BBC BASIC had ON ERROR. Usually used like:
10 ON ERROR GOTO 2000
....
2000 start of error-handling code
That's a bit like exception handling, but more like signal handling,
really. I have no idea how it was scoped; i think it wasn't, and the last
ON ERROR seen was used as the error handler. I understand other BASICs
have ON ERROR too, although i can't comment on how it works.
Shell script has a vaguely exception-like behaviour if you do "set -e": if
any command or function evaluates to a nonzero status, the script aborts.
If you structure your apps as multiple files, each doing set -e, then you
get a fail-fast behaviour that is like exceptions, with handling being
done using an || construct. I have scripts that do things like:
$(dirname $0)/start-server.sh || {
echo "Failed to start server: exit code $?"
$(dirname $0)/cleanup-server.sh
}
It ain't pretty, but, well, let's just say it ain't pretty.
tom