Annoying arrays

How come if you try to join a already joined array, it just completely errors? Why can’t it just skip if its already true?

That is like saying i can’t set a variable to true, because its already true, and then completely stopping your program and saying its not a function.

Anyway i can bypass this all together?

I’m not sure I understand what you are asking. Are you asking why in the third line here, we get an error?

let list = ['apple', 'beta', 'cat' ]
list = list.join(', ')
list = list.join('')

It’s because at that point list is no longer an array, it is a string.

How come if you try to join a already joined array…

To some extent, that is a nonsensical question. There is no such thing in JavaScript as an “already joined array”. At that point it is a string and has nothing to do with arrays. And since strings don’t have a join method, it doesn’t make any sense to call it.

It is our job to keep track of what our data is. If necessary, use clearer names. When I’m confused, I end string names with “Str” and array names with “Arr”.

1 Like

Ahh, I read about that naming convention. It’s popular in languages with type specific identifiers. I name my parameters abbreviated data types where the parameter name doesn’t matter, but that’s cool to hear someone adds the type in their identifiers.

Yeah, I don’t always do it, but if there is any doubt, I do. Sometimes I have an array and a string with the same name. Or sometimes I have too many variables switching types and it’s just easier to keep track.

If i do array.join("") twice i get a error.

Please show the specific code.

–> https://repl.it/@John_Nicole/Example

var equation = ["hello", "my"]
equation = equation.join("") // no error
equation = equation.join("") // error --> Not a function

When u first use join equation is an array but when u try to use join for the second time equation is a string and you can not use join on strings because strings doesnt have join method.

Yes, but why won’t it just skip over it then? At least don’t stop my program.

Short answer, what you’re doing was wrong, and you can get upset if you want, but it’s stopping your program because you’re doing something illegal, accessing a method that doesn’t exist. I’m thankful to be informed from my mistakes, especially when jumping between API’s all the time, and I’m not always referencing the documentation, it’s easy to make this mistake.

All the join method does is iterate over an iterable object adding a given string between the entries, concatenated to a new string, and returning that string. It appears under the judgement of who develops the API’s, this was unnecessary for strings. String has it’s own similar methods, such as String.replace() which can do the following

let str = "Amen";
str = str.replace("me", "gai"); // "Again"

There is no String.join() method, but you can add the Array.join() to the String object. There is no telling what consequences this may bring as the method is designed to work on arrays, but it appears to work somewhat.

String.prototype.join = Array.prototype.join;
"Amen".join(","); // "A,m,e,n,"

Your best bet, as always, is to learn and understand what you’re doing. Troubleshooting is part of the job and and such behavior is in place to protect us from our own mistakes, because we’re fallible.

2 Likes

If you want your program to continue, and skip over the offending line you can do this.


var equation = ["hello", "my"]
equation = equation.join("") // no error
try {
    equation = equation.join("") // error --> Not a function
} catch (ex){
    console.log("oops, I did someting stupid... error is " + ex.message); 
}

console.log("continuing...");

But really, it still doesn’t change the fact that the second equation.join() command is illegal.

So the above try…catch… construct is fruitless. Because it will always be an error.

You see, after your first join(), equation variable becomes a string and not an array anymore (thank JS for not having strict type checking).

There is no .join() method for a string variable… thus the error “not a function”

Thank you. Your reply was informative and i never new about the String object methods.

Did you know ‘emgo’ is Xhosia for ‘the pitch’ (south African language)

I wish there was a way to tell you that you cannot join a string in console, without stopping your program. This is because it is a innocent bug, and can’t actually affect anything.

That program @owel is pretty cool, never even knew try and catch were a thing. Basically it tries it, and
if (it works) {
its executed
} else {
its just telling me there is a error?
}

Yeah, I don’t know if try and catch is the best solution. This is the result of bad coding. I explained why in the first post on the thread. You have to keep track of what type the data is, especially in a language that is sooooo weakly typed like JS. Most languages will crash if you try an illegal operation. You can’t put a try and catch on every operation.

1 Like

Javascript does not have type checking. So if there are coding errors in your program, it would not tell you UNTIL time of execution, i.e. runtime error, your page stops, and hundreds/thousands/millions of users see a broken webpage.

Now, Typescript will do some error checking and flag this for you to avoid silly mistakes like this.

Type 'string' is not assignable to type 'string[]' 

That program @owel is pretty cool, never even knew try and catch were a thing. Basically it tries it, and if (it works) { its executed } else { its just telling me there is a error? }

You can tell it whatever you want to do as an alternate action… for example, in the try{} part you can be reading a database and if the database connection is unsuccessful, you can do some fallback, or tell the user “sorry, database is offline, try again later”… or pull the data from a secondary source, or do something else.

It did tell you. It has to stop the program. What if skipping that command and continuing would cause a corruption in your database? Or reveal sensitive information? No, it needs to crash unless you’ve specifically instructed it not to. The compiler does not know how to analyze your code and tell if it’s safe to continue or not.

Bugs like this happen. As you get more experienced, you’ll get better at preventing them. And better at analyzing them when they happen. But don’t blame JS.

@kevinSmith i can’t think of a scenario where not being able to join a already joined string would mess up a database.

@owel I will use that in the future to catch if something will error, its pretty cool. It can test code basically? and have certain outcomes.

Just remember, it’s not a cure for illegal code.

The try/catch is meant to catch any runtime error caused by an invalid input, or some scenario that you don’t expect normally… where instead of the program stopping unexpectedly, you route control of the program to do something else… or display an error message to the user and you perform housekeeping before shutting down intentionally.

@kevinSmith i can’t think of a scenario where not being able to join a already joined string would mess up a database.

Seriously? Are you joking? What if you are using it to compute the key/index name to replace the data in a database, data that is supposed to be overwritten but now is in two places (one correct and one incorrect) instead of overwritten in one? What if you loop through this a few thousand times? A few million? It really takes very little imagination. Or what if it deletes the wrong information? What if this is software for a stock trading company and you just told them to buy the wrong stock? It would take very little imagination to come up with scenarios where this would be a disaster.

This is getting to sound a little like the “put a bunch of things on one line” debate. You seem to want to tear down the basic tenets of good coding. These are fundamental principles here. Rather than argue when people try to explain these to you, perhaps it would be better to understand what they are saying. When you’re an expert coder, if you want to invent your own language that breaks all the rules, then go ahead. In the meantime, those “rules” are there for a reason.

And it still annoys me a little that I guessed the exact problem and explained exactly why it was happening in my first post but you ignored that and just went on a rant about how JS should just ignore errors. No, it shouldn’t. I don’t know of any language that does. I hope I never do. That would be a disaster.

I’m not saying it would in every case, but the big point is that JavaScript is not going to analyze your code, figure out every possible outcome, and tap into so supercomputer AI to determine if it is acceptable. It simply knows that if you are trying to apply a method to a string that doesn’t exist, so you clearly are confused. Don’t blame JS because you made a mistake. It is a poor dancer that blames the floor. This should be a lesson in keeping track of your data types. In strongly typed languages you wouldn’t even be able to attempt that. In JS, it trusts you to keep track.

This is not a bug in JS. This is a very important feature. Frankly, if JS didn’t do this, I’d be very worried. I’m very worried that now you think using try/catch is a good way to handle poorly planned code. As Owel says, it is meant for handling unexpected problems, like opening a file but the OS won’t let you, etc. I have this image of you wrapping every line of code in a try/catch or every time you have an error you don’t understand, applying a try/catch.

2 Likes

No I didn’t haha. Funny enough a username I made up as a kid, ‘Snigery’ is also a word in another language. Emgo is just the phonetic for the first letter in my first name, and the first two letters of my last name.

I completely agree, I was a bit frustrated, managed to boil down my reply after a few edits, hopefully it was applicable but I’m still in complete agreement with @kevinSmith. You really need to learn the whys, hows, whats, and reasons we do the things we do.

:100:

Agreed.

I was tempted to say the machine does this for us, but that’s not even true. The fact is those behaviors were designed and concluded to be for the best interest of the systems we work in. They are designed to fail when we do something obviously wrong. So again, still agreeing here.

Yeah, I just…just agree, it is kinda annoying to have these things questions especially when we (I’m sure) have been saved from those mistakes.

Now if you’re unsure why we have those systems perhaps a CS course or a CS textbook covering the history, or a computer engineering book? I don’t now personally, just some ideas, but there’s a really good reason for the way we’ve done things.

I recently discovered that you can add properties to a function. I thought it was the most amazing thing. I was trying to build a function that imitated the jQuery selector. I couldn’t figure out how to create an object that also worked like a function (I didn’t know about constructors).

Well I resolved this by making a function first, and then added my properties and methods to it. Tada! A class constructor. Now I don’t think everyone should do this, and really opened my eyes as to how everything is an object. But it was a great learning experience.

Even then I know I can encounter issues if I’m overriding a property or method part of that prototype. Sometimes learning what not to do is more helpful than learning what to do.

1 Like