I failed to mention: I am using vscode with
https://github.com/elixir-lsp/elixir-ls. I don't know if the experience
mentioned above differs when using other editors/plugins.
On Monday, May 4, 2020 at 5:37:14 PM UTC-6, Dallin Osmun wrote:
>
> I propose that we add `IO.error/2` which m
I propose that we add `IO.error/2` which matches the signature of
`IO.warn/2`. It emits error diagnostics/messages instead of warnings and it
causes the compile step to finish with :error.
*Reasoning*
Often when building a macro you'll do some validation and `raise` an error
if something
How would it behave if you remote console into a running
> system and call IO.error?
>
> On Monday, May 11, 2020 at 11:33:40 PM UTC-4, Dallin Osmun wrote:
>>
>> I understand at first glance this proposal might not seem necessary. I
>> wanted to give some insight into
le to emit
multiple errors. But now the compilation is successful. I have to rely on
my users actually exercising their code or having a good test suite to find
out that the output of the macro isn't actually going to work.
On Monday, May 4, 2020 at 5:37:14 PM UTC-6, Dallin Osmun wrote:
>
~ "Something broke"
While the code is indeed testable, I'm not sure if it is ideal. We may want
to add another macro to ExUnit.Assertions to help test code that uses
IO.warn and IO.error. Or maybe string matching in tests is good enough?
Thoughts?
On Tuesday, May 12, 2020 at 7:
Hi José,
Thanks for the helpful response!
What you are saying makes sense. I must admit I don't have a very advanced
knowledge of metaprogramming in elixir so I'll have to learn/practice a lot
more before I can come up with an informed response.
I tried out your suggestion and wanted to
hen emitting the warning, do "Macro.Env.stacktrace(__CALLER__)" to get
> the actual caller. You may also need to look at the AST to get the proper
> line. Note you would need to do the same if we were to introduce some sort
> of IO.error.
>
> On Fri, May 15, 2020 at 6:22 P
misnamed, but it is correct. But this
>>> behaviour in particular sounds like a bug in the editor itself, given it
>>> does have a line in the stacktrace specific to that file.
>>>
>>> On Fri, May 15, 2020 at 8:04 PM Dallin Osmun wrote:
>>>
>>>> I must