J
M
Martin Gregorie
PL/1 uses it pretty much like Java exceptions in that PL/1 exceptions
can't be ignored (unlike some BASICs) and there is nothing like a try
block.
BASIC was a nightmare: the dialects varied so wildly. Some worked as you
described while others let you specify what condition triggers each ON
CONDITION clause.
That ability to ignore errors at will is common to most operating system
macros as well as UNIX shell scripts.
VME/B had a better approach: the panoramic-conditional:
whenever (conditional expression that recognises exceptions)
begin
actions
end;
and these were scoped by the SCL block structure. SCL was the VME/B
command language.
It does what's needed. Its always a hard problem to write a command
language that works regardless of whether it is typed in line by line or
run from a file.
P
Pitch
Arguments are layed out in my previous posts but here they are again:
- exception chaining is nothing more than a reference to the root cause,
thus they have no functional purpose per se, unless we make use of those
references
- using those references brakes the Law of Demeter
Better alternative is to access only immediate exception, and not to
care about the cause.
EOD
L
Lew
Pitch said:
Not sure what your point is here. No reference anywhere in programming has a
"functional purpose per se, unless we make use of those references". The
program itself doesn't have a "functional purpose per se, unless we make use
of" it. The definition of "functional" is "we make use of it".
You only use exception chaining when you have a need for wrapped causes.
That was already refuted upthread. You are mistaken. The LoD doesn't apply
here because exceptions are "neighbor" classes to the caller; chaining simply
retrieves multiple instances of those neighbor classes.
That is not always better. There are valid scenarios when higher-level
exception handlers care about the chain of causality, e.g., for logging and
troubleshooting. The real world is a bitch.
P
Pitch
I will set a few examples where this is not so:
For example, take the length property of a string or an array. It is set
internally when the string is created. It is also used for various
calculations internal to String class.
Also, File class. Several properties like length, lastModified,
getParent, isHidden... are set when the object is created.
Also, URL class and itd getUserInfo is set automatically and is used by
several other classes.
Also, class Thread has getPrority, getState that are also used
internally.
You will see that all those properties are set internally and used by
the class or by some other class in the framework. I say they have their
purpose.
But the cause property of an exception is set by the programmer and used
by the programmer so it's a simple helper property. Something like
"Tag" or "Data" in some other languages and framework. It's not
something that will change the behaviour of the class or try-catch block
or enything in the whole JVM.
But it was not. Arve made a comment but he was wrong and I explained
why.
So you think PassswordException from user's Password-Service and
SqlException from JDBC are friend classes?
Citation from the Wiki page:
"an object should avoid invoking methods of a member object returned by
another method"
L
Lew
Lew says...
No, I think 'Throwable' is a "friend" type. 'getCause()' doesn't
return 'PasswordException' or 'SQLException'.
Since 'Throwable' is a friend, it's always OK to call methods on a
'Throwable'.
You've missed the point of LoD. Since the caller knows about
'Throwable' and that it has a 'getCause()' method, it is not reaching
into the member object's implementation to call 'getCause()' again,
therefore it is not violating LoD. It is using only the knowledge it
has of 'Throwable' to call 'getCause()' in a chain.
Anyway, 'getCause()' is far too useful to let foolish dogma restrict
one's use of it.
So you think PassswordException from user's Password-Service and
SqlException [sic] from JDBC are friend classes?
No, I think 'Throwable' is a "friend" type. 'getCause()' doesn't
return 'PasswordException' or 'SQLException'.
Since 'Throwable' is a friend, it's always OK to call methods on a
'Throwable'.
You've missed the point of LoD. Since the caller knows about
'Throwable' and that it has a 'getCause()' method, it is not reaching
into the member object's implementation to call 'getCause()' again,
therefore it is not violating LoD. It is using only the knowledge it
has of 'Throwable' to call 'getCause()' in a chain.
Anyway, 'getCause()' is far too useful to let foolish dogma restrict
one's use of it.
L
Lew
But we do make use of that property. That's why it's exposed to the
programmer. This does not refute the notion that "functional per se" is
equivalent to "we make use of it".
I still don't see what you mean. These properties have a functional purpose,
and we make use of them.
Again, have a "functional purpose per se" and "we make use of them".
This does not refute the notion that "functional" and "useful" are equivalent.
That makes it not functional, or somehow implies that we don't make use of it?
But it is something useful for a programmer.
By your reasoning, we should never use any property that has a 'setX()' method.
A
Arne Vajhøj
Pitch said:
Data carrying classes are very common.
Yes.
But that seems to indicate a problem with the general validity of that
not a problem with the code.
Far worse alternative.
Better to violate some obscure rule than to not be able to
trouble shoot an application, because the necessary information
is not available.
Arne
P
Pitch
Lew says...
Pitch said:So you think PassswordException from user's Password-Service and
SqlException [sic] from JDBC are friend classes?
No, I think 'Throwable' is a "friend" type. 'getCause()' doesn't
return 'PasswordException' or 'SQLException'.
LoD does not talk about type hierarchy, but of accessing instances.
I'm sorry but you misssed the point.
By your understanding any type can be a friend if you import it.
Remember, we are talking about e.g. Logger class accessing Throwable.
Anyway it's about instances and methods, not about types.
So you declare LoD a foolish dogma. Ok. I'm not saying it's practical to
write such code, but it's a guideline.
P
Pitch
()' method.
Only if it's modifying the behaviour of an object. I even belive that
Sun had been preparing something usefull for the getCause, maybe even it
would be made protected.
It would be better that getCause didn't exist at all, and that several
methods were introduced to access full chain of messages and stack-
traces.
P
Pitch
Yes, but they are used in some kind of framework, or in combination with
some other class. So the programmer sets these values so it can use the
object as input to another class.
I already indicated how both points could be achieved.
L
Lew
Arved Sandstrom already pointed out:
Pitch, you have completely misconstrued LoD to form a dogma that
interferes with effective programming.
P
Pitch
Yes, it's less effective but in the long run it's more effective since
you have less errors and better design.
J
jeremy
This is pretty much the Right Way To Do It.
But note that in this case, you have to be careful about using
IllegalArgumentException, as it's a RuntimeException. If code in a
deep
layer is doing input validation (say, taking a user-entered string and
looking something up in a database with it), then failure of
validation
needs to be signalled with a checked layer-specific exception,
otherwise
it will go through the upper layers and annoy the user.
On the other hand, if validation fails for a reason which could have
been
caught by an upper layer (a parameter is null, an argument is too long
or
the wrong colour, etc), then that's a programming error on the part of
the
upper layer, and it's okay to throw an IllegalArgumentException.
Although
it might still be wise to throw a checked exception.
Signature:
steve, cs
steve, cs
steve, cs