From java-user-return-54053-apmail-lucene-java-user-archive=lucene.apache.org@lucene.apache.org Mon Nov 5 02:30:49 2012 Return-Path: X-Original-To: apmail-lucene-java-user-archive@www.apache.org Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BF709DFA9 for ; Mon, 5 Nov 2012 02:30:49 +0000 (UTC) Received: (qmail 78864 invoked by uid 500); 5 Nov 2012 02:30:47 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 78831 invoked by uid 500); 5 Nov 2012 02:30:47 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 78822 invoked by uid 99); 5 Nov 2012 02:30:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2012 02:30:47 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trejkaz@trypticon.org designates 209.85.212.48 as permitted sender) Received: from [209.85.212.48] (HELO mail-vb0-f48.google.com) (209.85.212.48) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2012 02:30:39 +0000 Received: by mail-vb0-f48.google.com with SMTP id e21so6473321vbm.35 for ; Sun, 04 Nov 2012 18:30:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=XCgh3k8tHU4Z5HblGs6bubcIcTs/XbNZRGlyFCSXZqE=; b=nAtxdbHbmhpS4nNJ2Y1KY9IfG6RVW29PW3kCr3A7mFnYLtYRpZ4GicAR0yAUOZ+8X2 i/al2c1QlhhZi3JTBcCXl4eTOCPQPdA+Kta4tr8NR9JLCReBXJnELgnzLNTyQcGjBDrr jmG8U41hifuwSZYw4kwT9bGWWq5wpJFg0zafT8QUoP45A9sFhvc7VlCphdYv/3n+o6iB WRBR8kVioBzh3QsE2aimNPGymPdZm1aW+HV+rDQ2R768ln8t+zF4+yJEQEIbQ+Ux8zQb SzFOGODPzp91pykv0SWDIJJHLu9ikA/rqEVDGnTfIS3OyFbmzmLeUjdUw92wu9yN+ErB /+3A== Received: by 10.58.186.226 with SMTP id fn2mr8471499vec.33.1352082618251; Sun, 04 Nov 2012 18:30:18 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by mx.google.com with ESMTPS id xf2sm8019552vec.12.2012.11.04.18.30.17 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 18:30:17 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id e21so6473314vbm.35 for ; Sun, 04 Nov 2012 18:30:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.180.7 with SMTP id dk7mr8478462vec.30.1352082616124; Sun, 04 Nov 2012 18:30:16 -0800 (PST) Received: by 10.58.249.198 with HTTP; Sun, 4 Nov 2012 18:30:16 -0800 (PST) In-Reply-To: <5096A511.9020809@gmx.net> References: <20121102132000.167030@gmx.net> <5096A511.9020809@gmx.net> Date: Mon, 5 Nov 2012 13:30:16 +1100 Message-ID: Subject: Re: Excessive use of IOException without proper documentation From: Trejkaz To: java-user@lucene.apache.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlpgNJktAsULfOLTLLkv9ihtae42x5P9Cb8votdaWTnJFvaNjFkE7e4q8Za57x6fErGdHUr X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Nov 5, 2012 at 4:25 AM, Michael-O <1983-01-06@gmx.net> wrote: > Continuing my answer from above. Have you ever worked with the Spring > Framework? They apply a very nice exception translation pattern. All > internal exceptions are turned to specialized unchecked exceptions like > AuthenticationExceptoin, DaoAccessException, etc. I quite like unchecked exceptions. I think that checked exceptions have their place as a special return value, but once you're out of the one method which has the special return value, all other exceptions should really be unchecked. It wouldn't be so bad if it weren't for Java's compile-time checking that you have caught them. (A lot of the time you're dealing with parallel execution or caching APIs and the existence of a single checked exception means you now really do have to catch Exception...) IOException in particular is just awful, in my opinion. Everything which does I/O throws the exception, even though in tons of cases, the only thing which can cause it to be thrown is hardware failure, unplugging a disk or some rogue user going through and marking all your files read-only. All of these scenarios to me are along the same lines as running out of memory, yet OutOfMemoryError is an Error while IOException is a checked Exception. They realised their mistake and started to introduce IOError for these unexpected situations, but the APIs which already throw IOException are probably poisoned for life. I understand that there are legitimate cases of IOException, such as FileNotFoundException when trying to open a file which doesn't exist. But that is certainly not the sort which Lucene is propagating out through its API (or if it is, it shouldn't be.) As far as what users of Lucene are doing, in our case we're catching any IOException Lucene throws and wrapping it in an unchecked exception. If anything goes wrong with stores it's a pretty catastrophic situation which we won't be able to recover from anyway. And because IOException is being thrown with no additional information, it's not like we can make use of the information in the exception even if we caught it. TX --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org