Silent and Noisy errors

[joearms]

I just spent a good half an hour scratching my head.

I made the following error

I wrote:  `<<list-links filter:"[Prefix[How]]">>`

Instead of:

`<<list-links filter:"[prefix[How]]">>`

(I know it should be a small "p" and not a big "P" - but errors like this  (silent errors)

are extremely difficult to spot. I call errors like this `quiet errors`.

I have no idea how the filter mechanisms are implemented but it would be extremely helpful if all programming errors if they can be detected be converted into "noisy errors"

Noisy errors stop the program execution with a huge red error text telling you what went wrong. Quiet errors just swallow up the error and say nothing.

As a general design principle, I believe that all plugins etc should generate noisy errors if they detect an error condition.

Cheers

/Joe

[TonyM]

Joe,

I agree, but perhaps in this case is not even an error since Prefix could be a fieldname. I presume it was looking for the field called Prefix containing what is in the [] and since this was not the case it did not become true.

It is a nice feature you can write fieldname[value] as an operator that if fieldname equals value it is true.

Eg display-log[yes]

In a way you can create your own language like operators.

Can I suggest with all due respect, this is a learning opportunity that unless you have a good reason uppercase in filters means you may be referencing a field and or typo or a design error.

Regards
Tony

[@TiddlyTweeter]

Right. Its much worse for computer illiterate users like me who have no clear idea what is right and wrong in the lingo format.

I just assume that live feedback on coding errors would bloat TW beyond reasons for it.

Josiah

[PMario]

On Friday, December 14, 2018 at 7:48:01 PM UTC+1, joearms wrote:

I have no idea how the filter mechanisms are implemented but it would be extremely helpful if all programming errors if they can be detected be converted into "noisy errors"

This may help: https://tiddlywiki.com/#Filters:Filters%20%5B%5BIntroduction%20to%20filter%20notation%5D%5D%20%5B%5BFilter%20Syntax%5D%5D%20%5B%5BFilter%20Expression%5D%5D%20%5B%5BFilter%20Run%5D%5D%20%5B%5BFilter%20Operators%5D%5D

-m

[PMario]

Tobias Beer documented his thoughts, as he wanted to understand the filter system:

See http://tobibeer.github.io/tw/filters/# for more examples, that may help. BUT be aware that the TW is from 2015. TW has much more operators now!

have fun!

mario

[PMario]

On Friday, December 14, 2018 at 7:48:01 PM UTC+1, joearms wrote:

...

 

Noisy errors stop the program execution with a huge red error text telling you what went wrong. Quiet errors just swallow up the error and say nothing.

As a general design principle, I believe that all plugins etc should generate noisy errors if they detect an error condition.

You are right, but TW chooses a way, similar to, how browsers work. ... If a browser doesn't understand something, they just ignore it silently. ...

As you found out, that's sometimes painful for programmers and creators. ...

But it's convenient for consumers. If they see the red flag as in the ViewTemplate, they think: OK it's broken, close the page and never come back.

-m

[TonyM]

As Mario says, the silent failure is ultimately part of html's philosophical approach. There is some interesting histories of html that explains this.

We may expect a debug mode however I think this has being outsourced to Browser inspect tools.

Regards

Tony  

[Joshua Fontany]

I constantly test an adjust filter runs in the Advanced Search tiddler. Also, if you plug the filter into a $list widget, you can set a custom emptyMessage value, which will display if the filter returns no results. Good for when you know what to expect from your filter but it returns no results, not great when you have accidentally made a filter that returns unexpected results.

Also handy is the dumpvariables macro, which will list all current variable/macro values.