Where shoul I throw RuntimeException

G

Giovanni Azua

Hi Seamus,

Seamus MacRae said:
[snip]
That other thread started flaming big-time after, and only after, "Lew"
began to participate heavily, too; until then it had been only moderately
uncivil here and there and it has maybe calmed back down some since he
left it.
yes, here another one that didn't read the sign :]

I think it is a mistake to try to discuss anything with a Troll, all the
evidence shows what the underlying intentions actually are. After reading
all the deceits and insults no wonder why he needs to hide his true
identity.

Best regards,
Giovanni
 
G

Giovanni Azua

Hi Seamus,

Seamus MacRae said:
I don't believe he ever claimed that *disabled* assertions can do that. I
believe he claimed that code still under development could use *enabled*
assertions instead of RuntimeExceptions to do that, and I myself note that
production code will still bomb, whether it catches a RuntimeException in
a precondition check, an AssertionError (asserts still on), or a
RuntimeException from bounds checking, null dereferencing, or other
errors.
Thank you for the clarification but unfortunately I don't think it will
help, it is what it is.

Best regards,
Giovanni
 
S

Seamus MacRae

Giovanni said:
Hi Seamus,

Seamus MacRae said:
[snip]
That other thread started flaming big-time after, and only after, "Lew"
began to participate heavily, too; until then it had been only moderately
uncivil here and there and it has maybe calmed back down some since he
left it.
yes, here another one that didn't read the sign :]

I think it is a mistake to try to discuss anything with a Troll, all the
evidence shows what the underlying intentions actually are. After reading
all the deceits and insults no wonder why he needs to hide his true
identity.

Who, "Lew"?
 
G

Giovanni Azua

Hello Seamus,

Seamus MacRae said:
I disagree. Input validation (of interactive applications) should occur
using conditionals and divergent behavior in the presentation layer. For
instance if (i > 99) JOptionPane.blahblahblah("Size is too big; maximum
99")etc.etc.etc.return; else somethingInBusinessLayer.doSomethingWith(i);
(maybe make it localizable by using message bundle).
I don't disagree here. The "filtering layer" API e.g. service layer is not
supposed to replace this conditionals in the presentation layer. I think
this very same example is even explained in the book I cited before.

Assuming a multiple layer design you could rely on assertions to check for
preconditions in inner layers of the design. Analogous to the Java access
modifiers it would mean having a presentation tier, an application service
layer "exposed" that validates input, other inner layers e.g. could be the
data access layer "protected" would be a good candidate for use of
assertions for pre-conditions, java util etc would also be assertions-based
e.g. this is how Eiffel is.
This is debatable. The currently generally used best practices use
RuntimeException rather than assertions, but this tradition was
established before Java had assertions. The case could be made, but then
it would make sense to replace most or all RuntimeExceptions (and Errors)
with asserts and just have AssertionError, VMError, OOME, and (checked)
Exception. Well, were it not for backwards compatibility.
I don't think AssertionError should be handled. As I said before I disagree
that the "do not use assertions to check the parameters of a public method"
must be the rule for all cases. However, I think it should be the rule for
"exposed" API layers e.g. the application service layer, mostly depend on
the specific API.

Best regards,
Giovanni
 
L

Lew

Giovanni said:
I think it is a mistake to try to discuss anything with a Troll, all the
evidence shows what the underlying intentions actually are. After reading
all the deceits and insults no wonder why he needs to hide his true
identity.

I agree completely.
 
G

Giovanni Azua

Giovanni Azua said:
I don't disagree here. The "filtering layer" API e.g. service layer is not
supposed to replace this conditionals in the presentation layer. I think
this very same example is even explained in the book I cited before.

Assuming a multiple layer design you could rely on assertions to check for
preconditions in inner layers of the design. Analogous to the Java access
modifiers it would mean having a presentation tier, an application service
layer "exposed" that validates input, other inner layers e.g. could be the
data access layer "protected" would be a good candidate for use of
assertions for pre-conditions, java util etc would also be
assertions-based e.g. this is how Eiffel is.
The page 13 of these slides depict what I meant:
http://se.inf.ethz.ch/teaching/ss2005/0250/lectures/oosc_13_dbc_1up.pdf

There are some notes on defensive programming in page 17.

All course slides are here:
http://se.inf.ethz.ch/teaching/ss2005/0250/index.html#slides

I really enjoyed that course :)

Best regards,
Giovanni
 
G

Giovanni Azua

Tom Anderson said:
It definitely should not return null - that's almost never a good idea. It
shouldn't throw a RuntimeException, because that won't force the callers
to face up to the possiblity of failure. It could throw another checked
exception, perhaps a domain-specific one like DimkaDataLayerException,
rather an an SQLException. But what is certain - although others, who
labour in ignorance or sin, may disagree - is that it should throw a
checked exception. If there is a real possibility of failure, callers
should be made aware of it, and be made to prepare for it.
I don't think that the first thing one should figure out is what to throw or
rethrow. It is like the first thing that crosses your mind when you get a
client is to point the right "cannons" at him. Just thinking what is the
right cannon caliber "checked" or "unchecked" should not be the idea behind
serving a client. One should rather think hard to serve the client i.e.
require less and ensure more.

From my experience, the farther the exception gets the less likely any layer
will be able to recover and do anything sensible with it.
 
L

Lew

lol whom else? :) by now he even agreed to this lol.

Best!
Giovanni

I agree that trolls are problematic in a discussion. They ignore
evidence, even if it comes from the same authorities they themselves
profess to respect. They issue personal attacks against those who
disagree with them, resorting to epithets like "notorious", in lieu of
responding to the actual points. They ignore the logic of the
opposing viewpoint, resorting instead to character assassination
attempts. They use disparagement and doublespeak instead of logic and
evidence. They completely ignore points made that disagree with those
they proffer, attaching labels to their own reasoning like "Design by
Contract" even when the labels refer to concepts that contradict their
own points. When authoritative evidence is provided that the labels
do not apply to their own points, they merely reiterate the label, not
explaining how the contrary evidence might fail to apply to their
statements. Then they repeat the cycle of attempted ridicule and
character defamation in lieu of discussion of the logic of the
argument. Often they will employ the psychological technique of
projection, attribution of their own behaviors to those who disagree
with their conclusions.

In this discussion I and others have consistently provided evidence,
reasoning and logic, in agreement with other expert opinions, some
from those you yourself profess to hold as authoritative, that refute
some of your statements. It is in every piece of explanatory
literature that Design-by-Contract (DbC) involves establishment of
invariant, preconditions and postconditions in code with validation
logic to ensure that the contract is met. It is shown by
authoritative source and by reasoning through to consequences how
merely testing public methods internally cannot replace use of actual
runtime code to enforce such contracts. Likewise various respondents
in this thread have pointed out how the Java 'assert' construct cannot
substitute for if tests and possible exceptions to enforce contracts
of API methods. None of these respondents, myself included, have
attempted to disparage anyone's character or behavior in this
discussion, limiting our points to the facts.

The Usenet record makes it clear who has resorted to /ad hominem/
tactics, mere repetition of conclusions in lieu of supporting logic or
evidence, simple disagreement with sources authoritative even by their
own definition without evidence for such disagreement, and name
calling.

I agree with you that trolls are difficult to reason with, that DbC is
an important and effective development technique when properly
applied, that assertions should normally be disabled in production.

It is a matter of fact that in-development testing of public methods
without DbC enforcement clauses in their logic will not prevent bugs
in client code of those methods. It is a matter of fact that
assertions by themselves cannot enforce or guarantee correctness of
code. It is a matter of fact that experts at Sun and Eiffel have made
statements that agree with those conclusions. It is a matter of fact
that assertions play an important role in certain formal procedures of
code development and testing, including those proffered by Bertrand
Meyer.

It is a matter supported by evidence and logic in this discussion and
by referenced authorities that runtime checks involving constructs
other than 'assert', such as 'if' clauses and thrown exceptions, must
exist in production code in order to adhere to the principles of DbC.
It is a matter of fact that no argument other than simple disagreement
and /ad hominem/ attack has been offered in this thread to contradict
that conclusion.
 
L

Lew

The page 13 of these slides depict what I meant:http://se.inf.ethz.ch/teaching/ss2005/0250/lectures/oosc_13_dbc_1up.pdf

There are some notes on defensive programming in page 17.

Now I see what you meant and where you got your terminology.

Your view: API clients should guarantee preconditions.

If the Java method Math.sqrt() relied on that, what would it return
for 'Math.sqrt( -1 )'?

According to you, that would never happen. How do you guarantee
that? What would the result be?

My view, what you like to call "defensive programming": either the
method throws an exception or it tests the value and returns a
suitable value. The actual Java method 'Math.sqrt(double)' does the
latter; it returns 'Double.NaN'.

The method must handle the illegal input. No amount of concern for
"performance" relieves it of responsibility to handle a negative
input.

The problem with the Eiffel view of DbC, reflected in your remarks,
for Java is that programs cannot afford to fail in weird ways if a
client violates the contract. The supplier must handle whatever input
the client gives it; that's the nature of an exported API (i.e., all
public and protected methods). The usual Java mechanism to let a
client know it has violated its contract is a runtime exception such
as NPE. Sometimes it can do what the slides call a "tolerant"
approach, return a suitable value, as with 'Math.sqrt(double)'. You
just cannot prevent all future code written by all future programmers
from providing an illicit input.

Consider the Java method 'Arrays.binarySearch()'
static <T> int binarySearch( T[] a, int fromIndex, int toIndex, T
key,
Comparator<? super T> c )
et al.

Within the code there is an explicit check that 'fromIndex' is not
greater than 'toIndex'. From what you said, all client code should
enforce that, and relieve the library routine of the supposed
inefficiency of that check. How is it more efficient for a gazillion
callers to do a check centralized in one place in the 'Arrays' class,
as a private method, that alerts clients to their violation of the
contract via an 'IllegalArgumentException'?

How would you do it instead?
 
T

Tom Anderson

I don't think that the first thing one should figure out is what to
throw or rethrow. It is like the first thing that crosses your mind when
you get a client is to point the right "cannons" at him. Just thinking
what is the right cannon caliber "checked" or "unchecked" should not be
the idea behind serving a client. One should rather think hard to serve
the client i.e. require less and ensure more.

That's an admirable sentiment - if a method can recover from an exception,
then yes, it absolutely should (probably - there are times when it would
not be a good idea). My assumption in this thread has been that we're
talking about the times when it can't.
From my experience, the farther the exception gets the less likely any
layer will be able to recover and do anything sensible with it.

To a point - sometimes, the only sensible thing to do is to give up. Log
the exception, report failure to the user, whatever. That's a decision
that can only be made at the top level, and such errors can be escalated
to the top level most easily by throwing an exception.

tom
 
S

Seamus MacRae

Lew said:
I agree that trolls are problematic in a discussion. They ignore
evidence, even if it comes from the same authorities they themselves
profess to respect.

Or even each other?
They issue personal attacks against those who disagree with them
resorting to epithets like "notorious", in lieu of responding to
the actual points.

Just like you?
They ignore the logic of the opposing viewpoint, resorting instead
to character assassination attempts.

Just like the invading hordes from comp.lang.lisp?
They use disparagement and doublespeak instead of logic and evidence.

Just like you AND the invading hordes?
They completely ignore points made that disagree with those
they proffer

Seen a lot of that here lately, too.
Then they repeat the cycle of attempted ridicule and character
defamation in lieu of discussion of the logic of the argument.

You know, this sounds awfully familiar, but in reference to a different
thread and a certain invading horde. :)
Often they will employ the psychological technique of
projection, attribution of their own behaviors to those who disagree
with their conclusions.

This seems familiar too!
None of these respondents, myself included, have attempted to
disparage anyone's character or behavior in this discussion, limiting
our points to the facts.

Correction: "None of these respondents, "Lew" excluded, have attempted
to disparage anyone's character or behavior in this discussion, limiting
our points to the facts." The very post you just wrote, "Lew",
disparages Giovanni's character and behavior, as do the two I cited
previously as expressing an implication that he was a liar.
The Usenet record makes it clear who has resorted to /ad hominem/
tactics

Yes -- both of you.
It is a matter of fact that no argument other than simple disagreement
and /ad hominem/ attack has been offered in this thread to contradict
that conclusion.

I'm not sure that's entirely true.
 
G

Giovanni Azua

Hi Lew,

I acknowledge I read your email and I am really sorry it got this bad though
looking more into the positive side I hope this heat peak will turn the page
on insults and keep discussions at a mutually respectful and professional
level. As a side note, I just wanted to add that my retribution came only
after my many times biting my tongue to the several provocative and
unrespectful ways that you used to defend your arguments. I think your
"provocations" are the kick you use to trigger a fast throughout reply but
it is pushy and kind of defeats the purpose of the discussion at least for
me. I also noted you many times wrongly assumed I was either lying or being
arrogant while I really wasn't, I think improving in tolerance will help a
lot, maybe specially a bit more towards us non English native speakers e.g.
I sometimes end up picking the slightly wrong adjective, "worthless" turned
into a flame when I meant something more like "unnecessary" validation and
it is funny because I would like to defend an argument without having to
spend two hours looking in a dictionary for a neutral and politically
correct adjective ... it is a challenge but ok a good training too. If I may
recommend, I would say try to "ask first then shoot" rather than the other
way around.

Another side note, I personally don't like to have technical discussion
threads that are many pages long and defending many small unit of arguments
in parallel within a single thread each of these units also somehow spiced
with "toned" remarks that need lot of soft-skill efforts, it is a full time
job to respond to one of these. In general to improve the quality of the
discussion I think it is best to keep it short and well focused rather than
exploding exponentially as the threads that you get actively involved
usually tend to become. Well if you have to, then perhaps would be
preferable to have a separate reply for each of these topics or even create
a brand new thread. This is why I might have left some of your technical
valid points unanswered or just missed them. Also as a reader, I quickly
timeout if I see a very dense discussions specially toned with "uncivil"
remarks, it is a waste of time and energy.

Getting back into the original technical topic I think it is not completely
correct to discuss about assertions and look only into the documentation
pages at Sun and only into what they recommend to be the rules in this
regard. Assertions were introduced in Java as Sun itself claims as an
"informal design-by-contract style of programming". If we really are talking
about DbC then we should look into the source. Not doing so would be like
trying to understand how Java works by looking at the Microsoft VisualJ++
documentation. This is why I continuously kept referring to Bertrand Meyer
and his books and teaching materials, it is a fact that he is the
authoritative voice in the subject. The book I cited covers nicely the main
topic of this discussion, I wish I could quote at least some small excerpts
here but I guess that would be illegal. I think understanding how DbC works
from the source will help make better use of assertions in Java.

I will later respond to your other specific technical replies.

Best regards,
Giovanni
 
S

Seamus MacRae

Giovanni said:
The book I cited covers nicely the main topic of this
discussion, I wish I could quote at least some small excerpts
here but I guess that would be illegal.

No, quoting small excerpts in a noncommercial usage for commentary and
criticism would be fair use. The four traditional factors used to judge
if a use is fair are:
* Nature and character of the use -- noncommercial for commentary and
criticism, in this case, which favors a finding of fair use.
* Nature of the copyrighted work -- in this case, already published and
factual rather than fictional, both of which favor a finding of fair
use.
* Proportion of the work excerpted -- short quotes from a large book
favor a finding of fair use.
* Effect of the use on the potential market -- such quotes do not
compete with the complete book, and may in fact have the effect of
promoting it, which also favors a finding of fair use.

http://fairuse.stanford.edu/Copyright_and_Fair_Use_Overview/chapter9/9-b.html
has more information.

If you publish the work containing the quotations outside of the United
States, your mileage may vary, but it is highly unlikely that quoting
the book nonextensively while discussing and even promoting it in an
obscure usenet thread will lead to a lawsuit, and the above should give
you a clear conscience should you do so, even if you reside elsewhere
than the United States.
 
L

Lew

Giovanni said:
Getting back into the original technical topic I think it is not completely
correct to discuss about assertions and look only into the documentation
pages at Sun and only into what they recommend to be the rules in this
regard. Assertions were introduced in Java as Sun itself claims as an
"informal design-by-contract style of programming".

Sun says that they can be used in such a manner, not that they were introduced
for that purpose only. Assertions have been part of formal reasoning about
computer programming since at least 1969 and C.A.R. Hoare's work.
If we really are talking
about DbC then we should look into the source. Not doing so would be like
trying to understand how Java works by looking at the Microsoft VisualJ++

Assertions as a formal computer-programming mechanism predate Eiffel and
Bertrand Meyer's work generally. My interest was in assertions primarily; as
I understood it you introduced DbC in order to justify certain claims about
assertions.
documentation. This is why I continuously kept referring to Bertrand Meyer
and his books and teaching materials, it is a fact that he is the
authoritative voice in the subject. The book I cited covers nicely the main

But not the only or even primary authoritative voice on the subject of
assertions, which topic is where our subthread began.
topic of this discussion, I wish I could quote at least some small excerpts
here but I guess that would be illegal. I think understanding how DbC works

Quoting small parts of a work falls under "fair use" in most jurisdictions of
which I'm aware. You should cite the source and, if feasible, link to it, of
course.
from the source will help make better use of assertions in Java.

Assertions are part of DbC, but the converse isn't necessarily true. "Design
by Contract" is a trademarked phrase referring to one company's particular
advice for a specific style of programming in a particular language. I am not
so certain that it applies universally to all languages, for example, Java,
nor do I agree with all of your interpretation of it. As I have shown
upthread, even the authorities you cite don't completely support all your
claims. You also threw away authoritative remarks from sources you cited
yourself, to whit, the Sun document on the correct use of assertions.

The semantics of Eiffel's "ensure" and "require" don't have an exact parallel
in Java, AFAIK. Even Eiffel's examples, however, have idioms that seem
similar to what I've been recommending in this thread for Java programmers.

The facts are still facts. No amount of testing of a public method for a
subset of possible inputs to that method can stop a client method from passing
other inputs. A method must have some way of handling all possible input.

In Java, there are two possible responses to out-of-the-ordinary inputs -
return a reasonable value or throw an exception. It requires a method to do
one of three things - use an algorithm that accepts all possible inputs, such
as addition of two 'int' values does; branch after test to a different
algorithm for some subset of inputs, as a 'sqrt()' method might use for
negative input to return 'Double.NaN'; or branch after test to an
exception-throwing block. It just isn't possible for an exported method to
force client code to do those things for it, and even if it were, it wouldn't
be more efficient as the test would still happen somewhere anyway.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,772
Messages
2,569,593
Members
45,108
Latest member
AlbertEste
Top