Null world name
Amon.3275:
Sometime this morning, world_names.json started returning a null world name near the end of the list:
{"id":"1012","name":"Darkhaven"},
{"id":"2208","name":"Dasha [DE]"},
{"id":"2000","name":null},
{"id":"2025","name":"Fort Dunn"}]
I’m not sure if 2000 corresponds to a valid world whose name is now missing, or if it’s new.
Tanis.5134:
I noticed this as well, and it is causing problems.
On one hand, I’m afraid to filter it out in case it is a valid world. On the other hand, I don’t want to simply set that world’s name to “null” because that’s clearly not a world name.
Healix.5819:
If you feel like including it, simply change null to something like “Unknown”.
Based on their number system, the server would be EU server #0. 0 is typically reserved when numbering like this, where 0 would mean something like the entire group of EU servers or its entry point.
World #2000 is currently alive (https://api.guildwars2.com/v1/events.json?world_id=2000) and only moa racing is active on it so it’s probably a dev/test server or <moa racing conspiracy>.
Parthis.2091:
If Anet are including this it would be good to at the very least give it a name (as contractually, it should have a name), but I suspect it’s a test server, or something, and shouldn’t be there.
Regardless it is causing problems to many apps.
DarkSpirit.7046:
If Anet are including this it would be good to at the very least give it a name (as contractually, it should have a name), but I suspect it’s a test server, or something, and shouldn’t be there.
Regardless it is causing problems to many apps.
ArenaNet is a company with many teams. One team may not realize the impact it has on the other.
The best way to protect your app is to just you make your app more robust since screening for null, if you need to, is not difficult.
Parthis.2091:
If Anet are including this it would be good to at the very least give it a name (as contractually, it should have a name), but I suspect it’s a test server, or something, and shouldn’t be there.
Regardless it is causing problems to many apps.
ArenaNet is a company with many teams. One team may not realize the impact it has on the other.
The best way to protect your app is to just you make your app more robust since screening for null, if you need to, is not difficult.
You don’t need to explain software development concepts, or how large companies do things.
Name is pretty much mandatory in this context, so, it either needs a name or isn’t intended to make it into the dataset. There’s robustness, and then there’s ensuring every field is null-checked on the client as opposed to guaranteed by the service; on a field like ‘name’ in a read-only, user-focused API, that’s excessive.
Cliff Spradlin.3512:
Whoops. There was a configuration problem on one of our servers, causing this bug.
World 2000 is not a real world, which is why it doesn’t have a name.
Any references to world 2000 will be cleared out when the next game patch happens. Sorry for the inconvenience.
DarkSpirit.7046:
If Anet are including this it would be good to at the very least give it a name (as contractually, it should have a name), but I suspect it’s a test server, or something, and shouldn’t be there.
Regardless it is causing problems to many apps.
ArenaNet is a company with many teams. One team may not realize the impact it has on the other.
The best way to protect your app is to just you make your app more robust since screening for null, if you need to, is not difficult.
You don’t need to explain software development concepts, or how large companies do things.
Name is pretty much mandatory in this context, so, it either needs a name or isn’t intended to make it into the dataset. There’s robustness, and then there’s ensuring every field is null-checked on the client as opposed to guaranteed by the service; on a field like ‘name’ in a read-only, user-focused API, that’s excessive.
We have a totally different view of what Robust Programming is then.
http://nob.cs.ucdavis.edu/bishop/secprog/robust.html
Accidents and bugs do happen regardless of how much we hate them. Don’t trust any data from the Internet, even if your app has to fail due to unrecoverable errors, it should fail gracefully.
multivira.7925:
Yeah, but why does this happen right when I’m locked out of my hosting account so I can’t fix it on my site
I should’ve programmed it a bit more robustly indeed.
Parthis.2091:
Thanks for the confirmation Cliff.
If Anet are including this it would be good to at the very least give it a name (as contractually, it should have a name), but I suspect it’s a test server, or something, and shouldn’t be there.
Regardless it is causing problems to many apps.
ArenaNet is a company with many teams. One team may not realize the impact it has on the other.
The best way to protect your app is to just you make your app more robust since screening for null, if you need to, is not difficult.
You don’t need to explain software development concepts, or how large companies do things.
Name is pretty much mandatory in this context, so, it either needs a name or isn’t intended to make it into the dataset. There’s robustness, and then there’s ensuring every field is null-checked on the client as opposed to guaranteed by the service; on a field like ‘name’ in a read-only, user-focused API, that’s excessive.
We have a totally different view of what Robust Programming is then.
http://nob.cs.ucdavis.edu/bishop/secprog/robust.html
Accidents and bugs do happen regardless of how much we hate them. Don’t trust any data from the Internet, even if your app has to fail due to unrecoverable errors, it should fail gracefully.
We really don’t have a differing view on Robust Programming, Defensive programming or any other of the popularised terms meaning ’don’t write fragile code’. It’s all well and good taking the “yes you should have conditioned against that” line, but given that it’s an API that specifically exists to do one thing, and one thing only, and it’s doing that one thing differently now then it’s entirely understandable why some apps and frameworks are caught out, that’s all I was saying.
You can’t simply say “a null name from an API that deals in world names must be ignored” – that’s not robust, that is an assumption. Should it never make it into the dataset at the client end, or does the name become “Unknown” (if so, should the service do that, localised?), or does null now mean something important in the context of the API (world offline?) and is in-fact valid in the future.
You can’t null-check everything, at every point in every app. Syntactic-soup is the result.
I’m not critising Anet for this, mistakes happen and lessons are learnt.
DarkSpirit.7046:
You can’t simply say “a null name from an API that deals in world names must be ignored” – that’s not robust, that is an assumption. Should it never make it into the dataset at the client end, or does the name become “Unknown” (if so, should the service do that, localised?), or does null now mean something important in the context of the API (world offline?) and is in-fact valid in the future.
I am not saying to null-check everything. I am saying that you should check the validity of your data, taken from the api, before you process them, if you code based on those assumptions.
For example, if having a null value world name would cause your program to crash because your code assumes that world names would never be null, then you should have a check that world names from the api are indeed not null before your code uses the data.
What you decide to do upon encountering a null value world name is up to you, but at least you write code that caught it before it causes your program to crash down the line. It helps to be a little paranoid when it comes to consuming data from a third party API.
multivira.7925:
You can’t simply say “a null name from an API that deals in world names must be ignored” – that’s not robust, that is an assumption. Should it never make it into the dataset at the client end, or does the name become “Unknown” (if so, should the service do that, localised?), or does null now mean something important in the context of the API (world offline?) and is in-fact valid in the future.
I am not saying to null-check everything. I am saying that you should check the validity of your data, taken from the api, before you process them, if you code based on those assumptions.
For example, if having a null value world name would cause your program to crash because your code assumes that world names would never be null, then you should have a check that world names from the api are indeed not null before your code uses the data.
What you decide to do upon encountering a null value world name is up to you, but at least you write code that caught it before it causes your program to crash down the line. It helps to be a little paranoid when it comes to consuming data from a third party API.
Lesson learned indeed.