Error/Exception handling policy

[GoogleCodeExporter]

Rethink error-handling (or exception handling) policy before we go any further.

Original issue reported on code.google.com by d.ston...@gmail.com on 27 Aug 2009 at 2:32

[GoogleCodeExporter]

Three options:

  - C style asserts and aborts.
  - Boolean flag checking and error return values (aka posix).
  - Exceptions

Using c-style asserts and aborts is out. This is a library, so we can't crash 
the
application using it from within the library (sometimes the user needs to 
exit/abort
safely, e.g an ros node, so needs to identify the problem and handle it 
appropriately).

So that just leaves the other two. Exceptions I like, but this is costly in 
embedded
control. It would be ideal if you could turn off exceptions and have the library
still usable, or use only in debug mode. 

One design principle that is good:

Never leave an object in a dangerous state - i.e. so that it can be used after 
it has
been uninitialised properly. Force the programmer to deal with such objects 
when and
where they arise.

Original comment by d.ston...@gmail.com on 27 Aug 2009 at 2:39

[GoogleCodeExporter]

Ok, settled on keeping with exceptions, but a mix of debug/release exceptions 
where 
speed is critical and normal exceptions otherwise. 

In the future we'll rejig it so the whole library can be compiled without 
exceptions 
and the use of a single zombie flag that can be checked for the object status - 
up 
to the programmer than to handle that.

Original comment by d.ston...@gmail.com on 29 Aug 2009 at 6:14

• Added labels: Usability
• Removed labels: Milestone-0.2

[GoogleCodeExporter]

Original comment by d.ston...@gmail.com on 2 Sep 2009 at 1:37

• Added labels: Priority-Low
• Removed labels: Priority-Critical

[GoogleCodeExporter]

Moving to redmine issue tracking.

Original comment by d.ston...@gmail.com on 23 Dec 2009 at 3:46

• Changed state: WontFix