Currently call to DefaultHierarchyManager.isExists(String path) will end up with exception being logged and method returning false in case the invalid (i.e. containing invalid characters) path is passed in.
This issue is related to the JR issue [1]. As stated in the issue the warning is logged since JCR 2.0 mandates only valid XML characters to be used in the node names and with release of the JCR 2.0, the exception will be thrown instead of logging the warning.
JCR 1.0 does not restrict the characters names: Section 6.4.3 Escaping of Names ... "Not every item name is a valid XML name ... consequently for doc view serialization each content repo name is converted to a valid xml name by translating invalid characters ..."
instead JackRabbit, imposes some restrictions as described in the issue JCR-690 "... To keep such troublesome repositories compatible with 1.x, we could for now just make the name parser log warnings of invalid characters, and replace the warning with a thrown exception in 2.0..."
This issue have been already found in MAGNOLIA-2259 and solved directly in LinkFactory, however since it can be reproduced by other code paths (e.g. repeat the scenario described in MAGNOLIA-2259, but upload and save the image in DMS instead of via FCK), it should be solved in the DefaultHierarchyManager instead. For now, by using JR API to parse the path before call to Session.itemExists() and returning false in case of invalid path as of JR/JCR 2.0 by catching the exception and returning the false as well. Other possibility is to throw exception already now in case of invalid path, however since the method is merely checking for the existence of the path in the repository and invalid path can't exist I don't see this as an "exceptional" situation, but rather by a call fully within the contract of the method.

[1] http://issues.apache.org/jira/browse/JCR-690