Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of dawid.weiss@gmail.com
 designates 209.85.160.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5096D420.2040507@gmx.net>
References: <20121102132000.167030@gmx.net>
 <CAAHmpkjDr4rjuTrgbPpoEJf7zKA2eitgMJnJa_ru7n2Roc5FBQ@mail.gmail.com>
 <5096A511.9020809@gmx.net>
 <CALfq-2SPo_zQ_3DEsKrYeu5heKkqD-hVXQR5zVUH=59oqt-svQ@mail.gmail.com>
 <5096D420.2040507@gmx.net>
From: Dawid Weiss <dawid.weiss@gmail.com>
Date: Sun, 4 Nov 2012 21:52:17 +0100
Message-ID: 
 <CAM21Rt8DWXeBSkktXVBpZk=xU9u5g6rQz54UH7dHoAH47TayAw@mail.gmail.com>
Subject: Re: Excessive use of IOException without proper documentation
To: java-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=047d7b33d1a6878b8f04cdb18c6d

--047d7b33d1a6878b8f04cdb18c6d
Content-Type: text/plain; charset=UTF-8

> There is a tremendous difference. I have possibility at compile time to
detect whether an IOE came from Lucene or some other IO related action.

I agree with Shai -- there are just as many (or more) reasons not to create
custom exception classes and just reuse existing classes with known
semantics or propagate the original exception without wrapping it.

If you need to know exactly what caused the error then it's really your use
case and you'll have to live with bloated code. For most people IOException
is sufficient -- something related to I/O went wrong, that's it. These are
basically different extreme viewpoints of looking at the same code, there
is no right or wrong (regardless of the excellent references you provide).

Dawid

--047d7b33d1a6878b8f04cdb18c6d--