Why is your repo not a normal Mix project, created with mix new ...?
dimitarvp
chan11347
i have no idea 
my teacher just give a base code like this one and ask us to make it efficiency/ capacity and fault tolerance, that why i have the idea to make it unable put empty and werid value at the beginning.
0
chan11347
def add_entry(_server, _entry), do: {:error, "Invalid input"}
end
what is this line is about? before that three i have some idea what they are doing but this line seems like is doesn’t do anything?
0
lucaong
It is there just to return an {:error, cause} in case the entry is not an %Entry{} struct (for example, if the caller does something like add_entry(pid, nil)).
You might remove it, and in that case calling add_entry with something that is not an %Entry{} would raise an error (no function clause matching the input) instead of returning {:error, "Invalid input"}.
Both approaches could be reasonable, depending on the situation. If calling add_entry with something of the wrong type is not an expected situation, you can remove that line.
0
chan11347
is i input the wrong value?
if i put this line
def add_entry(_server, _entry), do: {:error, "Invalid input"}
is return the “Invalid input”
and if i run without it it become like this
0
lucaong
Yes, with your current code the entry must be an %Entry{} struct instead of a plain map, so you should call add_entry like this:
Todo.Server.add_entry(pid, %Todo.Server.Entry{date: ~D[2020-05-19], time: ~T[16:52:00], title: "Shopping"})
If you don’t want to type the whole %Todo.Server.Entry you can alias it:
alias Todo.Server.Entry
Todo.Server.add_entry(pid, %Entry{date: ~D[2020-05-19], time: ~T[16:52:00], title: "Shopping"})
0
chan11347
chan11347
iex(7)>Todo.Server.add_entry(testa, %Todo.Server.Entry{date: ~D[2020-05-19], time: [], title: "Shopping"})
:ok
iex(8)>Todo.Server.add_entry(testa, %Todo.Server.Entry{date: ~D[2020-05-19], title: "Shopping"})
**(ArgumentError) the following keys must also be given when building struct Todo.Server.Entry: [:time]
(todo) expanding struct: Todo.Server.Entry._struct_/1
iex(8)>Todo.Server.add_entry(testa, %Todo.Server.Entry{date: ~D[2020-05-19], time: ~T[], title: "Shopping"})
**(ArgumentError) cannot parse "" as time, reason: :invalid_format
(elixir)lib/calendar/time.ex:266: Time.from_iso8601~/2
(elixir) expanding macro: Kernel.sigil_T/2
iex:8: (file)
iex(8)>Todo.Server.add_entry(testa, %Todo.Server.Entry{date: ~D[2020-05-19], time: , title: "Shopping"})
**(SyntaxError) iex:8: syntax error before: ','
so i trying on other value to create the situation that is return “input cannot be be empty”, but is seems like the other error message will show up before the message
0
chan11347
so i trying on other value to create the situation that is return “input cannot be be empty”, but is seems like the other error message will show up before the message
0
lucaong
Yes, now the struct enforces the presence of all the keys. That’s good, because it enforces that an %Entry{} struct without the necessary options simply cannot be created.
That said, if you don’t want that, you can change the struct definition to:
defmodule Entry do
# remove @enforce_keys
defstruct date: nil, time: nil, title: nil
end
Make sure you understand the implications first though:
-
If you use a struct enforcing the keys, you enforce the presence of the keys whenever that struct gets created. That’s generally better, because it’s the developer’s job to make sure that the struct is created with the correct keys. In other words, it’s not a runtime concern. You still validate that the supplied values are not nil, because those values might come from user input, so that is a runtime concern, and you might need to give meaningful error messages to the user.
-
If you do not enforce the keys, when those keys are not set they will default to
nil, and your code will return an error tuple like{:error, "input cannot be empty!"}. This might sound useful, but if it’s the code that builds the struct wrong, an error message to the user won’t be useful.
1