The card may indeed be defective, obviously it must happen on occasion, but before assuming that there are a few simple things you can try.
Since you have a linux system on your laptop, try running fdisk -l /dev/sdb (presuming sdb is the card) and see what that says.
If it actually identifies partitions, try e2fsck /dev/sdb2, although from the sound of things the MBR is screwed up, meaning you won't find the partitions properly and so won't be able to fix any corruption on them (presuming that also exists, which it might not); fdisk will say something weird.
That is not the end of the world, though. The MBR is just a 1/2 kB block that contains basic information about what is supposedly on the card, partition wise, and where it is located. You can recreate the MBR fairly easily and since it is separate from the rest of the data on the disk, doing so should mean that data can be found again (it may actually be fine).
To do this you will need a copy of the image you originally used to flash the card; the image contains an MBR. This answer explains how to examine the information in it for the purpose of mounting the partitions to access them without having to burn to a card. The reason you want the a copy of the one you used originally is that periodically with Raspbian the first partition is expanded a bit, meaning the starting block of the second one changes. I download and mount Raspbian images regularly, and I have noticed this change at least once this year with the "lite" version.
If you do still have a copy of the image, you don't even have to bother looking at the MBR as described above -- you can just copy it onto the card.
dd if=whatever.img of=/dev/sdb bs=512 count=1
Note the of (output file) is the whole device there, not sdb1 or sdb2. This is the same as if you were burning the whole image, but the final two parameters here (bs = block size, count = number of blocks) are very important. It means all you are actually going to copy is the first 1/2 kB -- i.e., the MBR. This remains the same except if you've expanded the second partition; in that case you will want to think about that and make changes to with fdisk to match the real size of what is there.
After you do that, fdisk -l /dev/sdb should show the correct partition table. This doesn't mean you are completely out-of-the woods; you will first want to run e2fsck /dev/sdb2.1 You can also run fsck /dev/sdb1 to check/fix the first partition, but I would actually just try and mount and look at that instead and if it seems okay (you can compare it to the one in the image, read your config.txt, etc.) then not worry about it.
If e2fsck on the second partition comes out okay (if there is corruption, it may take some time; you may want to run it with -y so you do not have to keep saying answering "yes" to questions about fixing things) then you can mount that quickly and look at it. If fsck did a lot of stuff, check the lost+found directory. Normally it is empty, but post-fsck it will contain obscurely named files that are bits and pieces of things that could not be properly recovered. They may be useful for something if you have important stuff you want to try and sew together, but in this context just noting they are there and the total volume will give you a clue about how much data was effectively destroyed. If it is a lot, the partition may be infeasible -- you'll have to try a boot and see.
If in the end the card remains unusable, it's up to you whether you want to give it another chance or replace it. If the same thing then happens again, probably you should replace it; if it happens again with a different card, you should consider getting the Pi replaced, since they can be defective as well.
1. If you did grow the partition but did not set the size correctly in the replacement MBR with fdisk, the consequences may show up at this point, but beware fsck will not be able to correct the problem. A safe bet is to just make that partition as big as possible, since too big is okay, too small is not.
