From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] same functions everywhere From: Charles Forsyth In-Reply-To: <5258fb01cfa482d7b8d985e1c26dfac1@plan9.escet.urjc.es> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-olnrymjzpxeegscdbusvrwkbps" Date: Thu, 24 Apr 2003 13:20:24 +0100 Topicbox-Message-UUID: 97de3198-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-olnrymjzpxeegscdbusvrwkbps Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit sam and acme, for instance, have a good attempt at saving work-in-progress, and arguably a few others should too. --upas-olnrymjzpxeegscdbusvrwkbps Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-2.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1051185864:20:16206:34; Thu, 24 Apr 2003 12:04:24 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net id aa2121330; 24 Apr 2003 12:04 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3087419B96; Thu, 24 Apr 2003 08:03:11 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from sargazos.escet.urjc.es (sargazos.escet.urjc.es [212.128.4.206]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E688019A26 for <9fans@cse.psu.edu>; Thu, 24 Apr 2003 08:02:59 -0400 (EDT) Message-ID: <5258fb01cfa482d7b8d985e1c26dfac1@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] same functions everywhere From: paurea@plan9.escet.urjc.es In-Reply-To: <0127941e0d76aa164b1944de5701be00@mightycheese.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 24 Apr 2003 14:02:58 +0200 > The argument I think carries the day is that error handling is an > application-specific issue, not a library issue. I have written emalloc > several times but each application tends to do something different > in the error case. That is the real point. > Most of them do exactly the same, calling sysfatal. The only different thing is the error string and sometimes, it is just "out of memory" or variations on this. Gorka --upas-olnrymjzpxeegscdbusvrwkbps--