In an ideal world, requirements must be as complete as possible, and there would be no deviation from expectations, since all expectations would be translated into requirements.
In the real world, on the other hand, requirements are often incomplete, which makes room to unwritten expectations. Examples:
An application takes ten minutes to do the simplest task, making it totally unusable (see the answer of David Schwartz above).
An application has blue buttons, while the stakeholder hates blue and her favorite color is yellow.
All user's passwords are stored in plain text and shown to everyone who goes through "Forgot my password" procedure.
The visual design sucks.
The application sends sensitive information back to the developer. The developer also has a back door access to the application, letting him to do whatever he want.
You notice that some expectations are very easily translated into requirements. For example, the first one can be verified with a simple non-functional requirement related to performance:
The loading of [...] performs 85% of the time below 500 ms. when tested on machine with the performances specified in appendix G part 2 and the load below 15% for the CPU, below 40% for memory and no active R/W disk operations.
Others need not one, but several requirements. For example, the third one cannot be expressed as:
The system is secure.
Passwords are stored in a secure way.
since both are not the requirements: they are not precise enough and are subject to interpretation; they cannot be objectively tested. This means that you would need a requirement about the hashing algorithm, and several requirements about how "Forgot my password" procedure works by generating a password with a cryptographically secure pseudo-random number generator, then sending it by email.
Also, some expectations are close to objectiveness then others. At least, most people would agree that the fifth example illustrates something harmful: a developer doesn't have to have a full access to sensitive information, especially when he doesn't work on the project any longer. The same is not true for the point 4, and even more for the point 2: favorite color is something personal and cannot be a reasonable unwritten expectation for a project.
The objectiveness answers your question "[The] stakeholder could see a bug everywhere as he expected it to be like this or that..So how can I really know?":
If most people would have the same expectation for the same product, then you may want to implement the expectation. If you saved all the passwords plain text, it's up to you to correct this and to support the cost of the consequences. If, on the other hand, you hashed them with SHA512, but didn't use the salt, the stakeholder wouldn't be able declare this as a bug just because she expected PBKDF2 to be used instead.
If different people would have different opinions, then the stakeholder should have written more complete requirements, since you couldn't possibly know the taste of the stakeholder.
Note: remember to make the difference between common sense expectations and common practice expectations.
Some requirements are often omitted because they would cover a common practice, expected from any decent developer. Deviating from those practices, justifying it by the fact that there are no requirements, would be unprofessional. For example, I don't see a need to specify that a website must have no SQL Injection, unless I work with very inexperienced programmers.
Why those requirements are omitted? Because it would be to expensive to describe everything. Do we need to tell that a web application should use HTTP? Do we need to tell that it must use a database? Or that you don't save 1 GB-length files in a RDBMS, unless you use FILESTREAM feature of Microsoft SQL Server?
Example of a common sense expectation: "A website should be accessed from anywhere, not just from localhost." Well, yeah, that's what websites are for.
Example of a common practice expectation: "A website should use HTML 4, HTML 5 or XHTML." In fact, written from scratch HTML 3 websites are quite rare those days.