Currently there is no way in cryptofs to continue on an event and notify the user about it. By extending the API to add an event listener, the caller can be notified without throwing an exception and stopping the current code execution.
Problem Description
In cryptofs there are cases where it would be good to inform the user caller about certain events/findings (e.g. files not belonging to the vault structure, invalid dir directories), without interrupting the current call and throw an error. This is not possible, and as a developer you need to decide to either ignore/log the event or throw an exception. From the caller perspective this is not the most desireable case, because with this you might miss (for you) important findings.
Solution
Expose in the API a method to add an eventlistener and then notify the listener on predefined events. The predefined events should be documented somewhere. For example there could be an extended method for filesystem creation, where one can hand over the event listener.
Alternatives
Collecting all occuring, not critical exceptions and then hand them over (in some way) to the caller. But this would require again some side channel.
Summary
Currently there is no way in cryptofs to continue on an event and notify the user about it. By extending the API to add an event listener, the caller can be notified without throwing an exception and stopping the current code execution.
Problem Description
In cryptofs there are cases where it would be good to inform the user caller about certain events/findings (e.g. files not belonging to the vault structure, invalid dir directories), without interrupting the current call and throw an error. This is not possible, and as a developer you need to decide to either ignore/log the event or throw an exception. From the caller perspective this is not the most desireable case, because with this you might miss (for you) important findings.
Solution
Expose in the API a method to add an eventlistener and then notify the listener on predefined events. The predefined events should be documented somewhere. For example there could be an extended method for filesystem creation, where one can hand over the event listener.
Alternatives
Collecting all occuring, not critical exceptions and then hand them over (in some way) to the caller. But this would require again some side channel.