Not sure, if we should define our own FunctionalInterface for revealer to allow throwing checked exceptions..? 🤔

The question is, does it yield a value for the adapter to know that there was a problem during reveal? From my point of view no, because the mount object does not care if it is "revealable" from an external resource (revealer object). It even should only care about itself. If we enforce this caring by a checked exception, it would, from my point of view, only lead to a catch and rethrow.

On the other hand, the caller might know the revealer object and thus can handle possible the fitting, occuring RuntimeExceptions.

The call stack would be:

1. gui.clickedRevealButton()
2. mount.reveal(revealer)
3. revealer.reveal(path)

An exception thrown by 3. is expected to bubble up to 1., so that we can handle the exception where the whole command was invoked. If we want a checked exception, it is required to be thrown during 3. by revealer and not to be caught in 2. by mount.

For unchecked exceptions this is already taken care of, but the question is: Do we want the consumer of the API to be aware of the fact that this might fail? Imo, yes.

I second, that the API consumer should be informed of possible failure. Unfortunately, due to the inversion of control we have to wrap any exception occuring in revealer.reveal(path) only to unwrap it in the gui layer again, but I guess we cannot have both. Edit: i had a wrong understanding

I'll change the code.

Changes made in 2a4cc57.

The reveal() methods accepts now objects of types Revealer and throws RevealExceptions