From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] Error message for device not found at blkif.py Date: Wed, 18 Oct 2006 16:37:38 -0500 Message-ID: <45369EA2.5060201@us.ibm.com> References: <20061018200845.GB16266@redhat.com> <453695B2.9080307@us.ibm.com> <20061018212846.GC16266@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061018212846.GC16266@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Glauber de Oliveira Costa Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Glauber de Oliveira Costa wrote: > On Wed, Oct 18, 2006 at 03:59:30PM -0500, Anthony Liguori wrote: > >> Instead of throwing a VmError, could you subclass VmError with a more >> specific error and throw that? >> > Fore sure I can. But what does this condition have so differently from > others that justifies that for it only? Good question. Previously, we only threw opaque errors back over the wire. A few months ago, we changed that so that we could pass exceptions over the wire with specific Fault ids. The new Xend API should be even better for this. So, the answer we know have the ability to do useful things with this info so it's now a best practice for new code :-) I'm not suggesting you go change everything, just in your patch. Regards, Anthony Liguori > Although I agree with you that > such a specificiness is good, VmError is being thrown everywhere, meaning > that your proposal would require touching a great amount of code change. > Is there any plans/opposals for that? > > >