Re: [jgit-dev] Exceptions in jgit

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
> It's also very easy to convert a checked exception into a runtime
> exception if needed. The reverse is almost impossible, because you
> never know where they are.  So if someone using the JGit library
> really, really wants RuntimeExceptions they can write a wrapper
> class that fields it on. Heck, you could probably even auto-generate
> those ...
> 
> So, if we're writing a generic JGit library for any IDE which
> needs to report errors in a customisable way (i.e. not just
> System.out.println or try/catch/ginore) then you *have* to report
> that in a way that library callers know how to use. Anything buried
> in a RuntimeException has no real hope of translating into anything
> other than a message in a log-file or a somewhat less than helpful
> generic error box.
> 
> My thoughts are that libraries should declare checked exceptions,
> and make it part of the contract. I don't necessarily buy that you
> have to wrap everything in a JGitException - if you've got IO on
> the path, then having JGitException and IOException are fine. (We
> *really* don't want to be wrapping IOExceptions in RuntimeExceptions;
> that's basically the try/catch/ignore pattern.)
> 
> Speaking of exceptions, I think we should be creating specific
> exception subclasses rather than a generic exception with a message.
> That makes it easier to build specific customised error handling
> (whether that's message or retry operations) rather than using
> a switch on getMessage()). It should also be possible to embed
> specific data to the problem (like the objectid) which can be
> presented in an appropriate manner.

Alex, we don't always agree..., but here we do.  You stated what I
was trying to say way better than I ever could.  +1 and all that.

:-)

-- 
Shawn.