# \[F\] json API "catch" missing tag

**URL:** https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [September 21, 2014, 8:58pm UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166 "2014-09-21T20:58:23Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![vkostas](https://community.mp3tag.de/user_avatar/community.mp3tag.de/vkostas/32/227_2.png) [@vkostas](https://community.mp3tag.de/u/vkostas)
#### Post date: [September 21, 2014, 8:58pm UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166/1 "2014-09-21T20:58:23Z")

</div>

I started using the new Websource json approach. It is lovely. I found an issue (not necessary from mp3tag) and trying to find a solution.  
Websource script ends with an error when searching for omitted tag of the API response (e.g. [this](http://www.discogs.com/release/2993150) discogs release does not have any Style).  
With "traditional" webscript we could bypass this issue by adding `1` parameter (goto first character of the row in case of search failure).  
Do we have any similar solution with json now?  
If not then we have to add omitted tags to stream before starting json parsing to avoid all possible failures. Not an easy task. Can be very tricky.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [September 22, 2014, 3:31pm UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166/2 "2014-09-22T15:31:58Z")

</div>

Hi Victor,

thanks for your feedback! Glad you like the new JSON-related functions 🙂

I was thinking about the issue you're describing and what I would like the most is to make the functions error-safe in a way that, e.g., json\_select\_array would simply return nothing in case the given key does not refer to an array.

Using this approach, we can still check for any content using  
ifnot ""

What do you think?

Kind regards  
Florian

---

<div class="post-metadata">

### Author: ![vkostas](https://community.mp3tag.de/user_avatar/community.mp3tag.de/vkostas/32/227_2.png) [@vkostas](https://community.mp3tag.de/u/vkostas)
#### Post date: [September 22, 2014, 3:42pm UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166/3 "2014-09-22T15:42:50Z")

</div>

> [@Florian](#):
>
> Hi Victor,
> 
> thanks for your feedback! Glad you like the new JSON-related functions 🙂

I was so desperate about (missing) json parsing I wrote a very complex regexp script to convert json stream to pseudo xml format. Each element name included the whole path  
(e.g. "Format-\>Description", "Tracklist-\>Artist-\>Name", etc).

> [@Florian](#):
>
> I was thinking about the issue you're describing and what I would like the most is to make the functions error-safe in a way that, e.g., json\_select\_array would simply return nothing in case the given key does not refer to an array.
> 
> Using this approach, we can still check for any content using  
> ifnot ""
> 
> What do you think?
> 
> Kind regards  
> Florian

I like it!!!!!! I see no reason anyone would complain. As soon as the script does not fail all is good.  
Actually I had seen **ifnot ""** statement in the official json **discogs** script but couldn't find an explanation of its presence :-).

Kind regards,  
Victor

---

<div class="post-metadata">

### Author: ![vkostas](https://community.mp3tag.de/user_avatar/community.mp3tag.de/vkostas/32/227_2.png) [@vkostas](https://community.mp3tag.de/u/vkostas)
#### Post date: [September 22, 2014, 4:19pm UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166/4 "2014-09-22T16:19:47Z")

</div>

> [@Florian](#):
>
> Hi Victor,
> 
> thanks for your feedback! Glad you like the new JSON-related functions 🙂
> 
> Kind regards  
> Florian

I noticed something else (I found a workaround) which is "caused" by the **URL-UTF-8** encoding.  
API fails when using complex search (multiple parameters on the placeholder **%s** ). That's because **URL-UTF-8** encodes the ampersand character (&).  
I replaced encoding with **UTF-8** and complex search is back to life again.

Please consider some websript suggestions ([**in this new topic**](https://community.mp3tag.de/t/16169/1)).  
Please strogly consider point 4. I just realized we will lose "Advanced scripting" tricks by using json.  
Using "traditional" scripting we were collecting information on the selected API stream (use regexp, etc) and storing it to temporary tags, e.g. scan all tracks to find total number of discs to make it available to all tracks (in a new tracks loop).

---

<div class="post-metadata">

### Author: ![vkostas](https://community.mp3tag.de/user_avatar/community.mp3tag.de/vkostas/32/227_2.png) [@vkostas](https://community.mp3tag.de/u/vkostas)
#### Post date: [September 24, 2014, 4:06am UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166/5 "2014-09-24T04:06:46Z")

</div>

> [@Victor Kostas](#):
>
> Please consider some websript suggestions ([**in this new topic**](https://community.mp3tag.de/t/16169/1)).  
> Please strogly consider point 4. I just realized we will lose "Advanced scripting" tricks by using json.  
> Using "traditional" scripting we were collecting information on the selected API stream (use regexp, etc) and storing it to temporary tags, e.g. scan all tracks to find total number of discs to make it available to all tracks (in a new tracks loop).

I believe introducing a command (unless already there???) to move an output value back to selected API stream value would cover many of our needs and make json with only PROS against traditional scripting. Now it has a big showstopper for advanced scripting.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:07pm UTC](https://community.mp3tag.de/t/f-json-api-catch-missing-tag/16166/6 "2018-12-28T14:07:12Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
