[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [jgit-dev] Exceptions in jgit
|
> Personally, I think the project should adopt one style and stick with
> it.
Agree.
> 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.
I didn't mean throwing a RuntimeException but an application specific
subclass of RuntimeException. Anyway, there would be equal number of
people agreeing and disagreeing with what you wrote.
> 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.)
My experience show me that if a library author doesn't know what to
do with an IOException then, in most cases, the user of the library has
even less chance of doing something useful with it. In case of designing
a new API the user of such a library usually lets the IOException bubble up.
In case of dealing with an implementation of an already existing interface
that doesn't throw IOException he is then forced to wrap it into something
else that doesn't add any value.
> Speaking of exceptions, I think we should be creating specific
> exception subclasses rather than a generic exception with a message.
Agree. I think nobody proposed exceptions with a message only.
> 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.
This is doable both with checked and non-checked exceptions.
As a conclusion from my side:
I will accept any decision because we don't want a mixed approach. Further
technical argument is not necessary as we won't agree on purely technical level.
Sasa
