Drake
drake_throw.h File Reference

Detailed Description

Provides a convenient wrapper to throw an exception when a condition is unmet.

This is similar to an assertion, but uses exceptions instead of ::abort(), and cannot be disabled.

#include <type_traits>
#include "drake/common/drake_assert.h"
Include dependency graph for drake_throw.h:
This graph shows which files directly or indirectly include this file:

Namespaces

 drake
 

Macros

#define DRAKE_THROW_UNLESS(condition)
 Evaluates condition and iff the value is false will throw an exception with a message showing at least the condition text, function name, file, and line. More...
 

Macro Definition Documentation

◆ DRAKE_THROW_UNLESS

#define DRAKE_THROW_UNLESS (   condition)
Value:
do { \
typedef ::drake::assert::ConditionTraits< \
typename std::remove_cv_t<decltype(condition)>> Trait; \
static_assert(Trait::is_valid, "Condition should be bool-convertible."); \
::drake::internal::DrakeThrowUnlessWasUsedWithRawPointer< \
std::is_pointer_v<decltype(condition)>>(); \
if (!Trait::Evaluate(condition)) { \
::drake::internal::Throw(#condition, __func__, __FILE__, __LINE__); \
} \
} while (0)
std::enable_if_t< std::is_same_v< typename Derived::Scalar, Expression >, Eigen::Matrix< double, Derived::RowsAtCompileTime, Derived::ColsAtCompileTime, 0, Derived::MaxRowsAtCompileTime, Derived::MaxColsAtCompileTime > > Evaluate(const Eigen::MatrixBase< Derived > &m, const Environment &env=Environment{}, RandomGenerator *random_generator=nullptr)
Evaluates a symbolic matrix m using env and random_generator.
Definition: symbolic_expression.h:1334

Evaluates condition and iff the value is false will throw an exception with a message showing at least the condition text, function name, file, and line.

The condition must not be a pointer, where we'd implicitly rely on its nullness. Instead, always write out "!= nullptr" to be precise.

Correct: DRAKE_THROW_UNLESS(foo != nullptr); Incorrect: DRAKE_THROW_UNLESS(foo);

Because this macro is intended to provide a useful exception message to users, we should err on the side of extra detail about the failure. The meaning of "foo" isolated within error message text does not make it clear that a null pointer is the proximate cause of the problem.