It doesn't strictly need to be. For example, the API I reference above
returns a 32-bit error code but also takes an optional value-return
parameter that provides domain-specific error information. These additional
parameters can also be stacked so nested failures can be communicated. This
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not very
helpul about the cause of the error.
My suggestion is to return the
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not
On Apr 14, 2009, at 12:09 PM, Øyvind Harboe wrote:
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin lun...@mlu.mine.nu
wrote:
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
I'd rather know _why_ something failed rather than having to dig through the
code to figure out which layer and why. Not every user is a UNIX programmer
with intimate knowledge of the targets, interfaces, and general protocols.
That's what the LOG_ERROR()'s are for. They tell you where and
On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote:
I'd rather know _why_ something failed rather than having to dig
through the
code to figure out which layer and why. Not every user is a UNIX
programmer
with intimate knowledge of the targets, interfaces, and general
protocols.
That's
Rick Altherr wrote:
On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote:
I'd rather know _why_ something failed rather than having to dig
through the
code to figure out which layer and why. Not every user is a UNIX
programmer
with intimate knowledge of the targets, interfaces, and general
So because it isn't that way today, we shouldn't set a policy to do so in
the future?
I think that would be moving in the wrong direction, yes.
I'm in favour of a boolean success/failure return value and other mechanisms
to convey other information.
Why should information about what went
On Apr 14, 2009, at 2:11 PM, Øyvind Harboe wrote:
So because it isn't that way today, we shouldn't set a policy to do
so in
the future?
I think that would be moving in the wrong direction, yes.
I'm in favour of a boolean success/failure return value and other
mechanisms
to convey other
