Re: [boost] [boost.ublas] [gsoc'15]

Subject: Re: [boost] [boost.ublas] [gsoc'15]
From: David Bellot (david.bellot_at_[hidden])
Date: 2015-03-15 14:48:13

> For reporting singularities or similar conditions, there are really only
> two options, either throw an exception or return an error code, but only
> one of those two must be used consistently throughout uBlas. I personally
> prefer to work with exceptions, but I know that in this application domain
> it can be a very hard sell (especially with people wanting to use this in
> embedded systems). So, that really only leaves us with error-codes. That's
> what I would recommend.
>

​I think you're pointing to a complex problem. Indeed, assertions are
usually ​

​not a good idea and your use case is typical and quite common in fact.

___[For the potential GSOC students]___

Should we use exceptions or return codes ?​
​
​Again, as you pointed, exceptions are great, with almost no overhead
except when there is an ... exception. And most of the time, the execution
time ​is hard to predict. Which is far from being a good idea in a
real-time system.

I can't really say who the ublas users are, because there are a lot in all
sort of applications. Now, think about these 2 cases:

- you implement a multiplication algorithm for 2 matrices: you want your
algorithm to return the result and to be embedable into another expression,
that is you want to be able to write C =  A + (B*C). So it's important that
the return value is the result itself. Your only option to report an error
is to throw an exception. But it's hard to have a problem with a
multiplication (hard but not impossible),

- you implement a decomposition algorithm, and as a result you want 2
matrices (for example). You know that even for simple cases, you're going
to run a good and long algorithm. And have 2 values (i.e. 2 matrices) in
return. So it wouldn't be a bad idea to pass 2 empty matrices by reference
where to store the result (it's just an example, your design may vary), and
return a code which says if things went wrong or not. It could be a boolean
value, an enum, or anything that is quickly interpretable. And you really
don't want to include your decomposition algorithm into a bigger
expression. You can simply decompose your complex calculations and have one
line dedicated to the use of this decomposition algorithm.

Therefore, I think a return code is a better idea.