From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12318 invoked by alias); 15 Nov 2007 18:25:30 -0000 Received: (qmail 12305 invoked by uid 22791); 15 Nov 2007 18:25:29 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS,TW_FH X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 18:25:27 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lAFIPPX4008472 for ; Thu, 15 Nov 2007 13:25:25 -0500 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAFIPPO5020614; Thu, 15 Nov 2007 13:25:25 -0500 Received: from toner.toronto.redhat.com (toner.yyz.redhat.com [10.15.16.55]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAFIPOWB012823; Thu, 15 Nov 2007 13:25:25 -0500 Message-ID: <473C8F14.8030305@redhat.com> Date: Thu, 15 Nov 2007 18:25:00 -0000 From: Sami Wagiaalla User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Phil Muldoon CC: frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> <473C8D99.4060107@redhat.com> In-Reply-To: <473C8D99.4060107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00140.txt.bz2 Phil Muldoon wrote: > Mark Wielaard wrote: >> Hi Phil, >> >> On Thu, 2007-11-15 at 17:01 +0000, Phil Muldoon wrote: >> >>> As talked about on IRC over the corefile message design, exceptions >>> can and are used to carry warnings, messages and so on. How do you >>> differentiate between a warning and an error in this case? >>> >> >> By using different exception types, so a higher level can distinquish >> between a "recoverable" warning and a "unrecoverable" error. >> > > Like I mentioned in reply to Sami's email yesterday, having a napi > throw several different unchecked exception types places a huge and > unfair burden on the user to know the code beyond the api. The places > "must be an expert on Frysk to call Frysk apis" charge at our feet. The user doent have to know about any exceptions that are thrown and caught within the library (ie exceptions used for comunication). But if an exception bubbles up to that user, and we are following the system described above then that is infact an error and that user must have done something bad and should be notified in very clear manner.