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. 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. > 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. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Verified Express, LLC "Making the Internet a Better Place" http://www.verex.com/ _______________________________________________ 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>
