On Dec 15, 2006, at 12:23 PM, [EMAIL PROTECTED] wrote:
On Dec 15, 2006, at 17:06 UTC, Charles Yeomans wrote:
Passing a nil FolderItem to FolderItem.MoveFileTo results in a
NilObjectException. This is either a bug, or is working by design,
but is undocumented.
Undocumented maybe, but seems pretty obvious to me.
"This is behaving by design. You're passing in nil; what do you
expect to happen? The exception is an appropriate way to alert you of
the error."
What I would expect to happen is that the method would simply return
and set an error value in FolderItem.LastErrorCode, in keeping with
the design of the FolderItem class, as well as much of the REALbasic
framework.
I find myself in the rare position of disagreing with you (and
agreeing
with the evaluation in this case). FolderItem.LastErrorCode indicates
a file-system error; I'd expect that if, for example, you call
CreateTextFile on a FolderItem that points to a directory (or
otherwise
exists), or if you call Delete on a FolderItem that points to a
nonexistent file or one that can't be deleted because it's busy.
Those
are all problems at the file-system level. However, passing a nil
object to a method that requires a non-nil argument is a
REALbasic-level error, not a file-system one.
Okay, this makes sense.
What's the problem? You're attempting to use a nil object as the
destination (which must, of course, be non-nil). How do we signal
invalid attempts to use a nil object in REALbasic? We raise a
NilObjectException. Seems straightforward to me.
But, assuming arguendo that raising an exception is a reasonable
response, it should be documented because the raising of an exception
is then part of the method interface, as with, say,
Dictionary.Remove.
Well, I certainly wouldn't object to making that explicit in the docs.
Especially now that we have a separate page for every property and
method, they have a good place to put that level of detail.
And a NilObjectException is semantically ill-chosen. According to
the
REALbasic documentation, "A NilObjectException occurs when you use a
property or variable to access an object that doesn't exist.".
This is just the tech writer oversimplifying (as often happens) a bit
much. You and I understand RB much better than the writer probably
does. A NilObjectException occurs any time you attempt to access an
object via a reference that is nil. As it must, since there is no
object to access.
In this case, it seems obvious to me that since the destination of a
MoveFileTo operation is specified by a FolderItem object, RB will need
to actually access that object in order to carry out the
operation. If
that object doesn't exist (the reference you have passed in is nil),
then the exception is appropriate.
Obviously I disagree. I don't think this description of the meaning
of a NilObjectException is an oversimplification. When I see
f.MoveFileTo g raise a NilObjectException, my expectation is that f
is nil.
Here, the problem is that one
has passed a parameter that the method refuses to accept; in DBC
terms, it's a precondition violation. So the proper response would
be for REALbasic to define a RuntimeException subclass that captures
such a notion, and raise an instance of it here.
That wouldn't be a bad solution, I suppose, but it hardly seems
necessary in this case, when there is such a clearly applicable
exception already. Your argument for a "precondition violation"
exception (or perhaps more simply "bad argument exception") would be
stronger in cases where the argument were an integer or string or some
such, and could be out of range.
But oops, we already have OutOfBoundsException -- indeed, it seems
like
RB's approach is to provide something more specific than just "bad
argument." SomeArray(-5) is invalid because the argument is out of
bounds; f.MoveFileTo(nil) is invalid because the argument is nil.
And this is by choice. As I said earlier, an alternative choice
would be to simply fail, as Graphics.DrawPicture and other framework
functions do. I don't necessarily think that this is the right thing
to do, but at least it would be consistent.
In the end, this is the way MoveFileTo has been implemented for
several years, so I suppose that's an argument for not changing the
behavior. But it really should be documented, because there is no
other way to know whether the method is behaving as intended.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
