«

"Scott A. Hightower" <> writes:
>I seem to remember running across a reference to a discussion,
>consensus or policy regarding the guarantees of exception
>safety appropriate to Java. But I didn't capture it at the time
>and now have no idea where to look. Any pointers?

For every exception-safe method:

First, use operations that can throw to try to obtain
results, storing them in temporary variables

Make sure that all resources allocated in the preceding
step get released iff this block was left due to a
run-time error

(This might not be needed in C++, when it happens
automatically by RAII, in Java, something like this can be
done using »finally«.)

Otherwise, now assign the temporary results to the actual
result(s) of the function, using only operations that can
not throw

In other words: Every method has to be a transaction:
Either it succeeds and all resources are allocated
successfully, or it fails and no resource is allocated.
(To some extend, this also should be valid for
certain side-effects to the environment.)

For some reason, this topic seems to be omitted in the
Java culture. So, I have written my own ideas, above,
actually, ideas taken from the C++ community.

Stefan Ram wrote:
> (C) Copyright 2009 Stefan Ram. All rights reserved.
> Distribution through any means other than regular
> usenet channels is forbidden. It is forbidden to
> publish this article in the world wide web. It is
> forbidden to change URIs of this article into links.

<http://groups.google.com/group/comp.lang.java.programmer/msg/a99c5e17830ed474>

> It is forbidden to remove this notice or to transfer
> the body without this notice.

Is it permitted to transfer the notice without the body?

To follow up on what Peter said, how are we supposed to honor even such an
unenforceable copyright notice if we can't even read it without viewing the
headers, which I, at least, almost never do?

--
Lew

Scott A. Hightower wrote:
[ SNIP ]

> Sorry, I guess I wasn't concise.
>
> If someone is aware of a continuing discussion forum, a consensus or policy
> that addresses exception safety in Java, please post a pointer to it. Of
> particular interest are defined levels of guarantees appropriate to Java.
> What I seem to remember (and the memory is vague) was approximations to
> Basic, Strong and No Throw that accounted for asynchronous exceptions.
>
> But thanks for the quick response, anyway!
>
>
http://www.octopull.demon.co.uk/java...ionalJava.html

AHS

Scott A. Hightower wrote:
[ SNIP ]

> So, it took seven or eight years for the C++ community to reach a consensus.
> Exceptions were present when Java was introduced to the world, so we've had
> thirteen years. Are we close to "official" consensus? Is there even an
> ongoing "official" discussion?

I'm not aware of any ongoing "official" discussion. That doesn't mean
there isn't one.

Exception safety in the sense described in the article is a very valid
concern. I'm not aware of any way of coding methods to the basic and
strong exception guarantees (as described) other than the developer
being aware of state changes through the course of the method, knowing
where exceptions could be thrown in the method, and writing code to
handle those eventualities (ultimately ensuring that system state is not
unusable, or hasn't changed).

The author asserts (in 2002) that the Java community at large doesn't
keep these (by any name) exception safety benchmarks in mind when coding
methods. That's probably true for the majority of Java programmers.
However, I'd wager that good Java programmers do code to these
guidelines even if they're not aware of names for them.

AHs

Lew wrote:
> Stefan Ram wrote:
>> (C) Copyright 2009 Stefan Ram. All rights reserved.
>> Distribution through any means other than regular
>> usenet channels is forbidden. It is forbidden to
>> publish this article in the world wide web. It is
>> forbidden to change URIs of this article into links.
>
> <http://groups.google.com/group/comp.lang.java.programmer/msg/a99c5e17830ed474>
>
>
>> It is forbidden to remove this notice or to transfer
>> the body without this notice.
>
> Is it permitted to transfer the notice without the body?
>
> To follow up on what Peter said, how are we supposed to honor even such
> an unenforceable copyright notice if we can't even read it without
> viewing the headers, which I, at least, almost never do?

It's not so much unenforceable as simply superfluous, like any copyright
statement that forbids a whole bunch of things but doesn't grant
permission for anything. Since the default copyright on everything is
"all rights reserved" anyway, anything a copyright notice explicitly
forbids either was forbidden anyway, without needing an explicit
forbidding, or else is allowed anyway, because it's fair use.

Of course, we in the software world should be used to seeing such
superfluous copyright notices. Nearly every piece of software comes with
a ridiculously long and hard-to-read one. The refreshing exceptions are
the open source programs that come with notices explicitly granting
permission to do things normally reserved, such as distribute copies,
under some conditions, such as that you distribute the source.