On 2010-06-16 10:53:12 -0400, Andrei Alexandrescu
<[email protected]> said:
Leandro Lucarella wrote:
Steven Schveighoffer, el 16 de junio a las 06:55 me escribiste:
On Wed, 16 Jun 2010 05:28:46 -0400, Ary Borenszweig
<[email protected]> wrote:
On 06/16/2010 04:15 PM, Walter Bright wrote:
Ali Çehreli wrote:
bearophile wrote:
I have counted about 200 usages of std.contracts.enforce() inside
Phobos. Can you tell me what's the purpose of enforce() in a language
that has built-in Contract Programming?
I can see two benefits:
The difference is not based on those 3 points, but on what Andrei wrote
here. Contracts and error checking are completely distinct activities
and should not be conflated.
Could you please explain them? There are many people here that
don't understand the difference between these two concepts
(including me). So maybe we are too dumb, maybe those concepts are
not generally known or maybe the explanation is not very well
clear in the documentation.
I think of enforce as a convenient way translating an error in an
expectation to an exception in a single expression.
For example, take some system call that returns -1 on error, you
could do this:
if(result < 0)
throw new Exception("oops!");
or you could do this:
enforce(result >= 0, "oops!");
Think of enforce as "throw if"
So maybe throw_if() would be a better name =)
Anyway, I think enforce() is poisson,
Indeed it is a bit fishy :o).
because it make the programmer to
not think about errors at all, just add and enforce() and there you go.
But when you need to be fault tolerant, is very important to know what's
the nature of the error, but thanks to enforce(), almost every error is
a plain Exception, no hierarchy, no extra info, all you can do to get
a little more info about what happened is to parse the exception string,
and that's not really an option.
I think there is no real need for exception hierarchies. I occasionally
dream of eliminating all of the useless exceptions defined left and
right in Phobos.
The need is not really for a hierarchy. The hierarchy serves the need,
which is to:
1. Be able to programatically check the kind of the error and so your
program can act appropriately.
2. Propagate additional information related to the error and the
context it occured.
Displaying a proper error message to a user and offering relevant
recovery choices often need both. Sometime, a program won't ask the
user and attempt something by itself as a recovery. In both cases, you
need to know the kind of error, and may need context information.
And in fact, I think there's an errnoEnforce which throws a standard
exception with the string error from the system.
That's the only useful case of enforce, because it includes the
*important* information (the actual errno).
There is also enforceEx!(), to use a custom exception, which practically
nobody uses (I counted only 4 uses in phobos).
I'd be hard pressed to find good examples of exception hierarchy use.
Everybody talks about them but I've seen none.
The need is not really for a hierarchy. The hierarchy serves the need,
which is to:
1. Programatically check the kind of the error and so your program can
act appropriately.
2. Propagate additional information related to the error and the
context in which it occurred.
Displaying a proper error message to a user and offering relevant
recovery choices often need both. Sometime, a program won't ask the
user and attempt something by itself as a recovery. In both cases, you
need to know the kind of error, and may need context information.
That said, hierarchies are often abused, and aren't universally useful.
But exceptions should provide the above information in a way or another
when useful.
Think about a GUI program, if an exception is thrown somewhere during a
complex operation (say, reading a lot of files), I could catch it as
some level, create a wrapper exception with the context (file=hello.d
error=access denied) and rethrow it to unwind until reatching the GUI
error handler. Or the file function could throw a useful exception from
the start. In either cases, the code in charge of that operation can
display a message such as "Creating the archive failed. File 'hello.d'
could not be read because you do not have read permissions to it." with
options "Retry as Administrator", "Exclude 'hello.d'" or "Cancel".
Knowing programatically what has gone wrong is important in many cases.
The fact that the coder doesn't need to think hard to use enforce()
effectively is a plus, not a minus. An overdesigned enforce that adds
extra burden to its user would have been a mistake.
That's indeed true. Throwing an Exception with no info is still better
than not throwing at all, and creating useful exceptions isn't always
easy, nor economically rewarding. What's important is to make it easy
to improve the thrown exception when it becomes relevant. For instance
// first version: throws standard exception
enforce(1 == 1, "access denied to " ~ filename);
// refined version: throws custom exception
enforce(1 == 1, new FileException("access denied to " ~ filename,
accessDeniedError, filename));
--
Michel Fortin
[email protected]
http://michelf.com/
