Return to Answer

I think the concerns about redundancy and verbosity are probably well placed. ##andalso

The short circuiting logical AND is andalso. It can be used to simplify the code:

is_point({X, Y}) -> is_number(X) andalso is_number(Y).

Generally, the pattern:

// pseudo code
if f(x)
 return true
else
 return false

can be replaced with return f(x). Or in languages like Erlang where everything is an expression, f(x) alone is sufficient.

##Atoms

In Erlang, it is idiomatic to use atoms as the first level of data validation:

is_point({point, X, Y}) -> is_number(X) andalso is_number(Y).

More importantly, it aids in readability and debugging. Atoms let points be distinguished from football scores:

1> point:is_point({point, 3, 2}).
true
2> point:is_point({football_score, 3, 2}).
** exception error: no function clause matching 
point:is_point({football_score,3,2})
(/erlang/point.erl line 4) 

Note that using atoms and good function names provides most of what we want to start debugging this type of problem. Football scores are not points and "letting it crash" provides better information than badarg.

##Message passing

Labeling data with atoms lets us distinguish {rhombus, P1, P2} from {rectangle, P1, P2} and {circle, P1, P2}.

##Try-catch

Taking error handling code out of point:is_point is consistent with the "unwritten code is bug free" heuristic. If crashes are problematic, the caller should wrap the call to point:is_point/1 in a try-catch-finally block. The caller can handle the exception at whatever granularity it needs. And we can avoid the close coupling that coordinated error handling requires whenever the defaults are good enough.

I think the concerns about redundancy and verbosity are probably well placed.

andalso

The short circuiting logical AND is andalso. It can be used to simplify the code:

is_point({X, Y}) -> is_number(X) andalso is_number(Y).

Generally, the pattern:

// pseudo code
if f(x)
 return true
else
 return false

can be replaced with return f(x). Or in languages like Erlang where everything is an expression, f(x) alone is sufficient.

Atoms

In Erlang, it is idiomatic to use atoms as the first level of data validation:

is_point({point, X, Y}) -> is_number(X) andalso is_number(Y).

More importantly, it aids in readability and debugging. Atoms let points be distinguished from football scores:

1> point:is_point({point, 3, 2}).
true
2> point:is_point({football_score, 3, 2}).
** exception error: no function clause matching 
point:is_point({football_score,3,2})
(/erlang/point.erl line 4) 

Note that using atoms and good function names provides most of what we want to start debugging this type of problem. Football scores are not points and "letting it crash" provides better information than badarg.

Message passing

Labeling data with atoms lets us distinguish {rhombus, P1, P2} from {rectangle, P1, P2} and {circle, P1, P2}.

Try-catch

Taking error handling code out of point:is_point is consistent with the "unwritten code is bug free" heuristic. If crashes are problematic, the caller should wrap the call to point:is_point/1 in a try-catch-finally block. The caller can handle the exception at whatever granularity it needs. And we can avoid the close coupling that coordinated error handling requires whenever the defaults are good enough.

I think the concerns about redundancy and verbosity are probably well placed. andalso

The short circuiting logical AND is andalso. It can be used to simplify the code:

is_point({X, Y}) -> is_number(X) andalso is_number(Y).

Generally, the pattern:

// pseudo code
if f(x)
 return true
else
 return false

can be replaced with return f(x). Or in languages like Erlang where everything is an expression, f(x) alone is sufficient.

Atoms

In Erlang, it is idiomatic to use atoms as the first level of data validation:

is_point({point, X, Y}) -> is_number(X) andalso is_number(Y).

More importantly, it aids in readability and debugging. Atoms let points be distinguished from football scores:

1> point:is_point({point, 3, 2}).
true
2> point:is_point({football_score, 3, 2}).
** exception error: no function clause matching 
point:is_point({football_score,3,2})
(/erlang/point.erl line 4) 

Note that using atoms and good function names provides most of what we want to start debugging this type of problem. Football scores are not points and "letting it crash" provides better information than badarg.

Message passing

Labeling data with atoms lets us distinguish {rhombus, P1, P2} from {rectangle, P1, P2} and {circle, P1, P2}.

Try-catch

Taking error handling code out of point:is_point is consistent with the "unwritten code is bug free" heuristic. If crashes are problematic, the caller should wrap the call to point:is_point/1 in a try-catch-finally block. The caller can handle the exception at whatever granularity it needs. And we can avoid the close coupling that coordinated error handling requires whenever the defaults are good enough.

I think the concerns about redundancy and verbosity are probably well placed. ##andalso

The short circuiting logical AND is andalso. It can be used to simplify the code:

is_point({X, Y}) -> is_number(X) andalso is_number(Y).

Generally, the pattern:

// pseudo code
if f(x)
 return true
else
 return false

can be replaced with return f(x). Or in languages like Erlang where everything is an expression, f(x) alone is sufficient.

##Atoms

In Erlang, it is idiomatic to use atoms as the first level of data validation:

is_point({point, X, Y}) -> is_number(X) andalso is_number(Y).

More importantly, it aids in readability and debugging. Atoms let points be distinguished from football scores:

1> point:is_point({point, 3, 2}).
true
2> point:is_point({football_score, 3, 2}).
** exception error: no function clause matching 
point:is_point({football_score,3,2})
(/erlang/point.erl line 4) 

Note that using atoms and good function names provides most of what we want to start debugging this type of problem. Football scores are not points and "letting it crash" provides better information than badarg.

##Message passing

Labeling data with atoms lets us distinguish {rhombus, P1, P2} from {rectangle, P1, P2} and {circle, P1, P2}.

##Try-catch

Taking error handling code out of point:is_point is consistent with the "unwritten code is bug free" heuristic. If crashes are problematic, the caller should wrap the call to point:is_point/1 in a try-catch-finally block. The caller can handle the exception at whatever granularity it needs. And we can avoid the close coupling that coordinated error handling requires whenever the defaults are good enough.