データベースの行をタプルのリストからマップのリストに変換するために、リストの理解を使用します。ある日、データベーステーブルに新しい列を追加して、どこにいてもコードを変更することを忘れてしまいました。 そのため、私は奇妙な結果を発見しました。データベースの行は空のリストになります。 ERLコンソールのコードのErlangのリスト理解から予期しない空のリスト
例：この場合の右辺値の不一致：
> DbRows = [{1, 1, 1}, {2, 2, 2}].
[{1,1,1},{2,2,2}]
> [#{<<"col1">> => Col1, <<"col2">> => Col2} ||{Col1, Col2} <- DbRows].
[]
なぜアーランは例外エラーを生成しませんか？
このコードは問題ありませんか、このようなデータ変換を実行するには他の構文が優先されますか？
Erlangは正しい構文であるため、例外を生成しません。ジェネレータ{Col1, Col2} <- DbRowsは、同じ時間にフィルタです。パターンにマッチしない要素はスキップしました。 は、あなたのケースでは、私はそのような何かをするだろう：
-define(FIELDS, [id, some1, some2]).
DbRows = [{1, 1, 1}, {2, 2, 2}].
Prepare = fun(X) ->
maps:from_list(lists:zip(?FIELDS, tuple_to_list(X)))
end.
[ Prepare(Row) || Row <- DbRows].
をそして、あなたは新しいフィールドを追加するときは、マクロでそのフィールドを追加する必要があります。
私の経験ではバグを隠す傾向があるので、この「機能」は気に入らないが、あなたが見る結果の理由については、nikitの答えは正しい。
あなたはリスト内包の左側にパターンマッチングを移動することによって、例外を取得することができます：
[ case Row of {Col1, Col2} -> #{<<"col1">> => Col1, <<"col2">> => Col2} || Row <- DbRows ]
また、これはOPが期待する例外をスローしません。答えの一部を得ることは、何も役に立たないかもしれませんが、バグを発見するのが難しくなります。 –
本当に例外が必要な場合は 'Prepare = fun（X）'を 'Prepare = fun（X = {_、_}）'に置き換える必要があります。 – nikit