Date: Thu, 31 Jul 2014 22:04:34 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, marcel@freebsd.org, Phil Shafer <phil@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <20140801050434.82C9E580A2@chaos.jnpr.net> In-Reply-To: <58665.1406842603@critter.freebsd.dk> References: <201407312130.s6VLUFSP097778@idle.juniper.net> <58665.1406842603@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Jul 2014 21:36:43 +0000, Poul-Henning Kamp writes: >>sbuf looks like a simple case, returning either ENOMEM or the >>error code from the flush function. libxo can keep a "there's >>been an error" flag that the user can retrieve, but all the >>details of what's gone wrong would be lost. Or it can buffer >>the contents of warning messages and deliver it to the caller. >The point here is one of API design, and experience has shown >that either error-handling is convenient or it doesn't happen. > >I don't see the libxo case being any different from sbuf >in this respect, in fact I see it being almost even more >important because the readers are non-humans. The libxo case can be complicated by the structured output. If you have emitted <something> <here> <might> <fail> and then you encounter an exception, even if you output a nice <exception type="ENOMEM">sorry about that</exception> your peer may not cope unless you also close all the open elements: </fail></might></here></something> etc. Of course I wouldn't be surprised if the lib already handles all that ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140801050434.82C9E580A2>