I am trying to use the new
Logging system. I did a
@warn "a warning" x y z, where
x,y,z are complicated structures that I want to analyze. I see that
x,y,z get printed with the warning. Is there a way to access their values programmatically?
I am trying to use the new
Are you trying to access the content of the logged message or the content of the variables?
The contents of the variables, as they were when the message was generated.
Well that’s going to depend on what fields are available for your struct. What type/package/struct are you using/talking about?
For the purposes of this question, I think we can assume that
x is a
Vector (for example). I want to access this value of
x when the message was generated.
Well that’s just regular indexing - see here.
It would be helpful if you could provide more information about what you’re trying to do though…
I think I wasn’t clear enough. Here is an example.
function f(x) y = 2x @warn "something wrong" y end
Then at the REPL, or somewhereelse
julia> f(2) ┌ Warning: something wrong │ y = 4 └ @ Main REPL:3
At this point, how do I access the value of
y programmatically? Is there something like
LoggedValues[:y] that returns the value of
y when the message was issued?
y here is actually a complicated struct, so just looking at the printed value is no help.
Maybe I am confused here. I interpreted the following quote from the docs:
Second, the logging tools allow you to attach arbitrary data to each event as a set of key–value pairs. This allows you to capture local variables and other program state for later analysis. For example, to attach the local array variable
Aand the sum of a vector
vas the key
syou can use. (…)
as implying that there would be a way for me to access logged objects programmatically. For example, if something goes wrong in a computation involving a large matrix, I want to access the matrix programmatically (not just print it) to see what is going on.
No, that key-value pairing is just for printing and is not generally accessible after the message has been generated. If you would make that available later on after logging, you have to hang onto that old state somehow, which would be quite inefficent for some objects that would be logged.
You can check the code that’s doing that in the default
If you’re trying to do error handling, you’d be better off doing the handling explicitly in a
try-catch-block (or just throw an error and let the user handle it). The logging messages aren’t meant to be used that way - they’re generally only for user side informational purposes about an internal state - not for deciding on how to continue. If the struct you’re logging is too big, why log the whole struct?