From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25521 invoked from network); 12 Nov 2004 15:35:04 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 12 Nov 2004 15:35:04 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CSdS4-00047R-QB for arch-gentoo-dev@lists.gentoo.org; Fri, 12 Nov 2004 15:35:04 +0000 Received: (qmail 11770 invoked by uid 89); 12 Nov 2004 15:35:04 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 32 invoked from network); 12 Nov 2004 15:35:03 +0000 Date: Fri, 12 Nov 2004 10:30:25 -0500 X-OfflineIMAP-x568232651-70696d656e7473656e64-494e424f582e4f7574626f78: 1100273702-0776523893957-v4.0.7 From: Aron Griffis To: gentoo-dev@lists.gentoo.org Message-ID: <20041112153025.GB452@time.flatmonk.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20041111234522.40d8f48d@snowdrop.home> <419451F6.1010202@gentoo.org> <20041112070757.GA21178@tiger.gg3.net> <1100225464.8750.2.camel@localhost> <4194A18E.30106@gentoo.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <4194A18E.30106@gentoo.org> User-Agent: Mutt/1.5.6i Subject: Re: [gentoo-dev] einfo / ewarn banners and die messages X-Archives-Salt: c107742e-1d92-4673-b5a1-e62bf2d567ab X-Archives-Hash: 4d3ad7d28f6d11ac63d6edcbcc01a892 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Aaron Walker wrote: [Fri Nov 12 2004, 06:42:06AM EST] > Firstly, new* shouldn't need to die since they just cp and call their do* > counterpart, iirc. except that we'd want to see the correct die message. > Yes, I agree that things should install something or die, not ignore it. > However, IMO, it is considered better style to keep all that kind of > stuff in one place (the ebuild), just like it's usually considered > better to handle all signals and exit code in main() of a C/C++ app. I've made the same statement in the past. You might reconsider that position in the context of ebuilds. There is quite a difference: - In C/C++ it can be expensive to do up-front checking prior to calling into an API. Additionally the exception model of C++ makes it natural to do error handling in the caller rather than the callee. After all, how should the callee know what you want to do with errors? - When calling the aforementioned commands in ebuilds, there is never a situation when a failure is expected. If ever a command fails, the correct action is to die. Since that is the case, there is no reason to put all the error-handling code in the ebuilds themselves. It's just a burden on ebuild writers, and instead the errors often get ignored. Regards, Aron -- Aron Griffis Gentoo Linux Developer --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.10 (GNU/Linux) iD8DBQFBlNcRJrHF4yAQTrARAirqAKDKEZYwHS4QcwLAZrSmArZrhdA9vgCcCreo 4LfHeQ4VXCvYIMBa8iVR64k= =DLkC -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv--