Forum Discussion
Hard to Catch Error
Hello,
Could someone on the Microsoft side confirm what’s going on in a certain hard to catch error scenario?
For both of the below examples:
- Query Editor display an error message (“Expression.Error: bad”).
- However, changing the let expression’s result clause from “Data” to “try Data” doesn’t catch the error. Instead, the record output by the try has field HasError = false even though accessing its Value field results in the UI displaying an error.
Why doesn’t “try Data” catch this error?
My guess as to what’s going on:
- Data evaluates to a valid table (as demonstrated by “Data is table” returning true and “Table.Schema(Data)” outputting a valid schema table). Since Data outputs a value, “try Data” doesn’t see any error to catch so reports HasError = false.
- Instead, the error is raised when Query Editor tries to display the table. Query Editor, after starting an enumeration of the table’s values, requests that the first row be streamed. This requires that the row’s expression be evaluated—an attempt which fails with an error, which Query Editor dutifully displays in its UI in place of the table.
- “try Data” doesn’t help here because Data outputs a valid table. Even though how the UI displays the error makes it look like it came from Data, the error actually occurred after Data’s expression is evaluated and its value returned.
- To catch this error, it’s needful to put the try where it will actually “see” (encounter) the error. This will occur if the try precedes an access to the table’s first row. “try Data{0}” catches this error.
Is this anywhere close to correct? 🙂
Thank you,
Ben
Examples
let
Data = Table.View(null,[GetType = () => type table [ABC=any], GetRows = () => error "bad"])
in
Data // an error is displayed in Query Editor
// try Data // record's HasError = false but if its field Value is accessed, an error is displayed
// Data is table // returns true
// Table.Schema(Data) // returns schema table
let
Source = Table.FromList({error "bad"}, Splitter.SplitByNothing(), {"Column1"}),
Data = Table.ExpandTableColumn(Source, "Column1", {"abc"})
in
Data // an error is displayed in Query Editor
// try Data // record's HasError = false but if its field Value is accessed, an error is displayed
// Data is table // returns true
// Table.Schema(Data) // returns schema table
Simply referencing the value apparently doesn't raise an error. But enumerating the rows does.
What happens if you do this?
try Table.Buffer(Data)
This should force the enumeration of the rows.
EDIT: Note that there may be other less-expensive ways to initiate enumeration. Buffering is just the first thing that came to mind.
Thanks, Ehren.
For triggering the enumeration with minimum expense, I'm attracted to "Data{0}?", based on the thought that it has the advantage of only pulling at most one row—just enough to cause the error to be raised.
3 Replies
- EhrenMicrosoft Employee
Simply referencing the value apparently doesn't raise an error. But enumerating the rows does.
What happens if you do this?
try Table.Buffer(Data)
This should force the enumeration of the rows.
EDIT: Note that there may be other less-expensive ways to initiate enumeration. Buffering is just the first thing that came to mind.