> 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. Th
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
Øyvind Harboe wrote:
> There are a couple of problems with C++:
>
> - there is no consensus to use it for OpenOCD. This will be
> *hard* to arrive at since there are a lot of deeply embedded
> developers that we need for OpenOCD to succeed.
> - there is a lot of messy & nasty C++ libraries. I'd hat
There are a couple of problems with C++:
- there is no consensus to use it for OpenOCD. This will be
*hard* to arrive at since there are a lot of deeply embedded
developers that we need for OpenOCD to succeed.
- there is a lot of messy & nasty C++ libraries. I'd hate to see
something as simple as
> 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 wro
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, interfa
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 wh
> 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 12:09 PM, Øyvind Harboe wrote:
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin
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 (
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin 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 very
> helpu
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 mo
11 matches
Mail list logo
