>> It's not entirely clear to me what the return value of File#delete() means. > Did an error occur, or did the file simply not exist to begin with? If the > latter, I think the code is probably fine as-is. If the former, we should > probably check the return value and throw a QueryException if false. >> > Note that file#delete will not throw an error if the delete is not possible, > take a look here for example: > http://www.exampledepot.com/egs/java.io/deletefile.html
Yes, I understand how to process a boolean return value. :-) But the Javadoc for File#delete() does not make it clear what the return value means (see above). > So wouldn't be good to have the doDelete (indicating if the resource has > been deleted or not, like in the doPut) return a boolean: > created = doPut(path, value); > so we could have > deleted = doDelete(path, value); > and behave like in the other method ... > but maybe for the 2.1 to not break here method signature, ok ? I don't see any need to change the method signature. If a caller tries to delete a file that doesn't exist, we return an HTTP 404. Returning a boolean in this case would be inconsistent with the HTTP spec. >>> And last: >>> tests/src/org/apache/pivot/tests/ShutdownTest.java:55 >>> Unchecked/unconfirmed >>> cast from org.apache.pivot.wtk.Dialog to org.apache.pivot.wtk.Alert >>> ... >> Ignore all these. The casts are valid. > Ok, but I guess if for the 2.1 could make sense to change a little their > generics signature to have compile-time checks for these like <Y extends X>, > but it's a small thing ... They aren't generics.
