Browse Source
Swallowing intermittent errors and trying to recover from them makes JGit's behavior hard to predict and difficult to debug. Propagate the errors instead. This doesn't violate JGit's usual backward compatibility promise for clients because in these contexts an IOException indicates either repository corruption or a true I/O error. Let's consider these cases one at a time. In the case of repository corruption, falling back e.g. to an empty set of refs or a missing ref will not serve a caller well. The fallback does not indicate the nature of the corruption, so they are not in a good place to recover from the error. This is analogous to Git, which attempts to provide sufficient support to recover from corruption (by ensuring commands like "git branch -D" cope with corruption) but little else. In the case of an I/O error, the best we can do is to propagate the error so that the user sees a dialog and has an opportunity to try again. As in the corruption case, the fallback behavior does not provide enough information for a caller to rely on the current error handling, and callers such as EGit already need to be able to handle runtime exceptions. To be conservative, keep the existing behavior for the deprecated Repository#peel method. In this example, the fallback behavior is to return an unpeeled ref, which is distinguishable from the ref not existing and should thus at least be possible to debug. Change-Id: I0eb58eb8c77519df7f50d21d1742016b978e67a3 Signed-off-by: Jonathan Nieder <jrn@google.com>stable-5.3
Jonathan Nieder
6 years ago
1 changed files with 7 additions and 9 deletions
Loading…
Reference in new issue