Re: [jgit-dev] Exceptions in jgit

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

"Zivkov, Sasa" <sasa.zivkov@xxxxxxx> wrote:
> > I'd like to move to more specific checked exceptions, and stop
> > throwing back any old IOException to the application caller.
> > But this is a fairly major effort, and I'm just struggling to
> > get the sideband protcol change implemented to match Git 1.7.0.2.
> > I've basically written it off as something I just can't do.
> 
> Why checked exceptions?
> I don't want to start yet another discussion on checked vs non-checked
> exceptions in general since it often goes into discussing
> personal preferences.

Quite true.  This is similar to that emacs/vi debate.  Nah, its
more like the debate about whether or not there should be a blank
line between field declarations in a Java class, because everyone
on the project has to live with one guy's opinion.  :-)

Personally, I feel that exceptions thrown out of a method are part
of the method's return-value contract, and therefore they should
be declared to the caller by the throws clause, and the calling
method should be forced to handle those results.  Java's checked
exceptions provides that.

Others certainly disagree, and often will counter my argument with
return values should be proper return values.  So a method should
return a status result... and pass its computed result perhaps
through an output parameter.  Except Java doesn't have a great way
to do output parameters. :-)

I sit maybe 15 feet away from Joshua Bloch.  I should actually
just have a chat with him and see what advice he can offer here.

Methods like RevWalk.parseCommit() can fail because the ObjectId you
feed them isn't a commit.  Or doesn't exist.  Or, they can return
a RevCommit.  IMHO, callers should be prepared to handle these
conditions when they occur... even if that means just declaring
that they themselves rethrow it.

But its really just my personal preference.  My intern last summer
was extremely against checked exceptions.  His preference actually
leaned towards returning a wrapper object that looked like this:

  class Result<T> {
    public final T value;
	public final Throwable failure;
	Result(T t) { value = t; failure = null; }
	Result(Throwable e) { value = null; failure = e; }
  }

I think that makes it hard to combine calls together quickly.
Clearly RuntimeException is somewhere between the two...

Anyway, checked vs. unchecked is probably something we'll never
fully agree on as a project.  But in most cases, I favor having
checked exceptions.

> However, as you wrote, there are also some
> practical issues with checked exceptions like calling a method
> that throws a checked exception inside the hasNext() method of
> an Iterator. It often leads to wrapping the checked exception into
> another exception without any added value.

Yes.  In my opinion this is one of the huge design mistakes in Java.
Err... perhaps the real mistake was allowing the two classes of
exceptions and thereby forcing programmers into this position in
the first place.


Anyway.  Despite my personal prefernces, I won't turn patches away
if they make a noticable improvement in API usage for applications.

-- 
Shawn.