Markus Armbruster writes:
> Markus Armbruster writes:
>
>> QEMU's Error was patterned after GLib's GError. Differences include:
> [...]
>> * Return value conventions
>>
>> Common: non-void functions return a distinct error value on failure
>> when such a value can be defined. Patterns:
>>
03.07.2020 10:38, Markus Armbruster wrote:
Markus Armbruster writes:
Vladimir Sementsov-Ogievskiy writes:
28.04.2020 08:20, Vladimir Sementsov-Ogievskiy wrote:
27.04.2020 18:36, Markus Armbruster wrote:
FYI, I'm working on converting QemuOpts, QAPI visitors and QOM. I keep
running into b
Markus Armbruster writes:
> Vladimir Sementsov-Ogievskiy writes:
>
>> 28.04.2020 08:20, Vladimir Sementsov-Ogievskiy wrote:
>>> 27.04.2020 18:36, Markus Armbruster wrote:
FYI, I'm working on converting QemuOpts, QAPI visitors and QOM. I keep
running into bugs. So far:
[...]
I go
Vladimir Sementsov-Ogievskiy writes:
> 28.04.2020 08:20, Vladimir Sementsov-Ogievskiy wrote:
>> 27.04.2020 18:36, Markus Armbruster wrote:
>>> Markus Armbruster writes:
>>>
Markus Armbruster writes:
> QEMU's Error was patterned after GLib's GError. Differences include:
[...]
28.04.2020 08:20, Vladimir Sementsov-Ogievskiy wrote:
27.04.2020 18:36, Markus Armbruster wrote:
Markus Armbruster writes:
Markus Armbruster writes:
QEMU's Error was patterned after GLib's GError. Differences include:
[...]
* Return value conventions
Common: non-void functions retur
27.04.2020 18:36, Markus Armbruster wrote:
Markus Armbruster writes:
Markus Armbruster writes:
QEMU's Error was patterned after GLib's GError. Differences include:
[...]
* Return value conventions
Common: non-void functions return a distinct error value on failure
when such a valu
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> QEMU's Error was patterned after GLib's GError. Differences include:
> [...]
>> * Return value conventions
>>
>> Common: non-void functions return a distinct error value on failure
>> when such a value can be defined. Patterns:
>>
On Mon, Apr 06, 2020 at 11:05:36AM -0300, Eduardo Habkost wrote:
> On Sat, Apr 04, 2020 at 12:59:27PM +0200, Markus Armbruster wrote:
[...]
> > Paolo, Daniel, Eduardo,
> >
> > Please pick one for QOM:
>
> Replying this without reading the whole discussion and context:
>
> >
> > * Do nothing. L
On Sat, Apr 04, 2020 at 12:59:27PM +0200, Markus Armbruster wrote:
> Paolo, Daniel, Eduardo,
>
> Please pick one for QOM:
> * Return true on success, false on error. Looks like
>
> if (!object_property_set_bool(..., errp)) {
> return;
> }
My preference is this one, since it
On Sat, Apr 04, 2020 at 12:59:27PM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Markus Armbruster writes:
> >
> >> QEMU's Error was patterned after GLib's GError. Differences include:
> > [...]
> >> * Return value conventions
> >>
> >> Common: non-void functions return a
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> QEMU's Error was patterned after GLib's GError. Differences include:
> [...]
>> * Return value conventions
>>
>> Common: non-void functions return a distinct error value on failure
>> when such a value can be defined. Patterns:
>>
Markus Armbruster writes:
> QEMU's Error was patterned after GLib's GError. Differences include:
[...]
> * Return value conventions
>
> Common: non-void functions return a distinct error value on failure
> when such a value can be defined. Patterns:
>
> - Functions returning non-null poin
Vladimir Sementsov-Ogievskiy writes:
> 02.04.2020 18:06, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> 02.04.2020 11:55, Markus Armbruster wrote:
Peter Maydell writes:
> On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
> wrote:
>> Someho
BALATON Zoltan writes:
> On Thu, 2 Apr 2020, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>> 02.04.2020 12:36, BALATON Zoltan wrote:
[...]
Not much better. Could it be something like:
[...]
ERRP_RET(object_property_set_link(cpuobj,
OBJECT(&s->cpu_contain
On 02/04/20 10:55, Markus Armbruster wrote:
>
> When you return non-null/null or true/false on success/error, neglecting
> to document that in a function contract can perhaps be tolerated; you're
> using the return type the common, obvious way. But when you return 0/-1
> or 0/-errno, please spell
02.04.2020 18:06, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
02.04.2020 11:55, Markus Armbruster wrote:
Peter Maydell writes:
On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
wrote:
Somehow, in general, especially with long function names and long parameter
l
On Thu, 2 Apr 2020, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
02.04.2020 12:36, BALATON Zoltan wrote:
On Thu, 2 Apr 2020, Vladimir Sementsov-Ogievskiy wrote:
01.04.2020 23:15, Peter Maydell wrote:
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
QEMU's Error was p
Vladimir Sementsov-Ogievskiy writes:
> 02.04.2020 11:55, Markus Armbruster wrote:
>> Peter Maydell writes:
>>
>>> On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
>>> wrote:
Somehow, in general, especially with long function names and long
parameter lists I prefer
02.04.2020 11:55, Markus Armbruster wrote:
Peter Maydell writes:
On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
wrote:
Somehow, in general, especially with long function names and long parameter
lists I prefer
ret = func(..);
if (ret < 0) {
return ret;
}
Personally I pre
Vladimir Sementsov-Ogievskiy writes:
> 02.04.2020 12:36, BALATON Zoltan wrote:
>> On Thu, 2 Apr 2020, Vladimir Sementsov-Ogievskiy wrote:
>>> 01.04.2020 23:15, Peter Maydell wrote:
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
>
> QEMU's Error was patterned after GLib's GErr
On 4/2/20 12:54 AM, Markus Armbruster wrote:
Peter Maydell writes:
It's a small improvement. A bigger one is
if (object_property_set_link(cpuobj, OBJECT(&s->cpu_container[i]),
"memory", errp)) {
return;
}
if (obje
02.04.2020 12:36, BALATON Zoltan wrote:
On Thu, 2 Apr 2020, Vladimir Sementsov-Ogievskiy wrote:
01.04.2020 23:15, Peter Maydell wrote:
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
From my POV the major problem
On Thu, 2 Apr 2020, Vladimir Sementsov-Ogievskiy wrote:
01.04.2020 23:15, Peter Maydell wrote:
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
From my POV the major problem with Error as we have it today
is that it
Daniel P. Berrangé writes:
> On Thu, Apr 02, 2020 at 07:54:11AM +0200, Markus Armbruster wrote:
>> Peter Maydell writes:
>>
>> > On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
>> >>
>> >> QEMU's Error was patterned after GLib's GError. Differences include:
>> >
>> > From my POV the m
Peter Maydell writes:
> On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
> wrote:
>> Somehow, in general, especially with long function names and long parameter
>> lists I prefer
>>
>> ret = func(..);
>> if (ret < 0) {
>> return ret;
>> }
>
> Personally I prefer the other approach
On Thu, Apr 02, 2020 at 08:11:11AM +, Peter Maydell wrote:
> On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
> wrote:
> > Somehow, in general, especially with long function names and long parameter
> > lists I prefer
> >
> > ret = func(..);
> > if (ret < 0) {
> > return ret;
>
On Thu, Apr 02, 2020 at 07:54:11AM +0200, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
> >>
> >> QEMU's Error was patterned after GLib's GError. Differences include:
> >
> > From my POV the major problem with Error as we have it to
On Thu, 2 Apr 2020 at 07:11, Vladimir Sementsov-Ogievskiy
wrote:
> Somehow, in general, especially with long function names and long parameter
> lists I prefer
>
> ret = func(..);
> if (ret < 0) {
> return ret;
> }
Personally I prefer the other approach -- this one has an extra line
in the
02.04.2020 8:54, Markus Armbruster wrote:
Peter Maydell writes:
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
From my POV the major problem with Error as we have it today
is that it makes the simple process of
Peter Maydell writes:
> On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
>>
>> QEMU's Error was patterned after GLib's GError. Differences include:
>
> From my POV the major problem with Error as we have it today
> is that it makes the simple process of writing code like
> device realize f
01.04.2020 23:15, Peter Maydell wrote:
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
From my POV the major problem with Error as we have it today
is that it makes the simple process of writing code like
device rea
On Wed, 1 Apr 2020 at 10:03, Markus Armbruster wrote:
>
> QEMU's Error was patterned after GLib's GError. Differences include:
>From my POV the major problem with Error as we have it today
is that it makes the simple process of writing code like
device realize functions horrifically boilerplate
Alex Bennée writes:
> Vladimir Sementsov-Ogievskiy writes:
>
>> Side question:
>>
>> Can we somehow implement a possibility to reliably identify file and line
>> number
>> where error is set by error message?
>>
>> It's where debug of error-bugs always starts: try to imagine which parts of
>>
Daniel P. Berrangé writes:
> On Wed, Apr 01, 2020 at 11:02:11AM +0200, Markus Armbruster wrote:
>> QEMU's Error was patterned after GLib's GError. Differences include:
>>
>> * &error_fatal, &error_abort for convenience
>
> I think this doesn't really need to exist, and is an artifact
> of the l
Vladimir Sementsov-Ogievskiy writes:
> Side question:
>
> Can we somehow implement a possibility to reliably identify file and line
> number
> where error is set by error message?
>
> It's where debug of error-bugs always starts: try to imagine which parts of
> the error
> message are "%s", and
Vladimir Sementsov-Ogievskiy writes:
> 01.04.2020 12:02, Markus Armbruster wrote:
>> QEMU's Error was patterned after GLib's GError. Differences include:
>> * &error_fatal, &error_abort for convenience
>> * Error can optionally store hints
>> * Pointlessly different names: error_prepend() vs.
01.04.2020 15:44, Daniel P. Berrangé wrote:
On Wed, Apr 01, 2020 at 11:02:11AM +0200, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
* &error_fatal, &error_abort for convenience
I think this doesn't really need to exist, and is an artifact
of th
On Wed, Apr 01, 2020 at 11:02:11AM +0200, Markus Armbruster wrote:
> QEMU's Error was patterned after GLib's GError. Differences include:
>
> * &error_fatal, &error_abort for convenience
I think this doesn't really need to exist, and is an artifact
of the later point "return values" where we com
01.04.2020 15:10, Vladimir Sementsov-Ogievskiy wrote:
01.04.2020 12:02, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
* &error_fatal, &error_abort for convenience
* Error can optionally store hints
* Pointlessly different names: error_prepend()
01.04.2020 12:02, Markus Armbruster wrote:
QEMU's Error was patterned after GLib's GError. Differences include:
* &error_fatal, &error_abort for convenience
* Error can optionally store hints
* Pointlessly different names: error_prepend() vs. g_error_prefix() and
so forth *shrug*
* Propag
QEMU's Error was patterned after GLib's GError. Differences include:
* &error_fatal, &error_abort for convenience
* Error can optionally store hints
* Pointlessly different names: error_prepend() vs. g_error_prefix() and
so forth *shrug*
* Propagating errors
Thanks to Vladimir, we'll soon
41 matches
Mail list logo
