Tag Info

Hot answers tagged

199

Your project is big enough already. In my experience, one class and one function have been sufficient to consider the need for unit testing. class Simple { boolean reallySimple() { return true; // how do we make sure it doesn't change to false? } } class SimpleTest { void assertReallySimple() { ...


101

I've never bought into the "you must unit test everything" idea, though there are certainly folks out there who have (see gnat's answer!). As far as I'm concerned, the main benefits of unit testing are: Helping ensure changes don't break things. Helping you design sensible interfaces to your classes (since it forces you to be a client to your own code). ...


97

I would strongly advise against #1, because just ignoring errors is a dangerous anti-pattern. It can lead to hard-to-analyze bugs. Setting the result of a division by zero to 0 makes no sense whatsoever, and continuing program execution with a nonsensical value is going to cause trouble. Especially when the program is running unattended. When the program ...


76

Quit. No, not your job! Just get up and go home. You're done for the day or the weekend. 19 times out of 20 when you come back to the problem next, the solution will present itself within an hour.


65

I tend to build an application log, either in DB or in file, and log all such information to that. You can then give the user an error number, which identifies which log item the error is related to, so you can get it back. This pattern is also useful as you can follow errors even if the users don't bother raising them with you, so you can get a better idea ...


61

0 is false because they’re both zero elements in common semirings. Even though they are distinct data types, it makes intuitive sense to convert between them because they belong to isomorphic algebraic structures. 0 is the identity for addition and zero for multiplication. This is true for integers and rationals, but not IEEE-754 floating-point numbers: ...


59

The question is not so much whether you should check for null or let the runtime throw an exception; it is how you should respond to such an unexpected situation. Your options, then, are: Throw a generic exception (NullReferenceException) and let it bubble up; if you don't do the null check yourself, this is what happens automatically. Throw a custom ...


59

It's not so much "fake" performance as real responsiveness. There are a number of reasons why it's popular: Internet connections are fairly reliable nowadays. The risk of an AJAX request failing is very low. The operations being performed are not really safety critical. If your emails don't get deleted on the server, the worst that happens is you have ...


58

In my mind, the biggest argument is the difference in what happens when the programmer makes an error. Forgetting to handle an error is a very common and easy mistake to make. If you return error codes, it is possible to silently ignore an error. For example, if malloc fails, it returns NULL and sets the global errno. So correct code should do void* ...


58

Because the math works. FALSE OR TRUE is TRUE, because 0 | 1 is 1. ... insert many other examples here. Traditionally, C programs have conditions like if (someFunctionReturningANumber()) rather than if (someFunctionReturningANumber() != 0) because the concept of zero being equivalent to false is well-understood.


54

While Steven's answer provides a good explanation, there is another point which I find is rather important. Sometimes when you check an error code, you cannot handle the failure case immediately. You have to propagate the error explicitly through the call stack. When you refactor a big function, you may have to add all the error-checking boilerplate code to ...


42

Before ten hours go by, I would get some help. Describe the problem to someone else, anyone else, even your rubber duck. Ask someone else to take a look at the code, or step through it with them. Isolate it. Delete a bunch of stuff, then bring it back bit by bit until the problem reappears. Get some sleep!


41

Exceptions were invented to help make error handling easier with less code clutter. You should use them in cases when they make error handling easier with less code clutter. This "exceptions only for exceptional circumstances" business stems from a time when exception handling was deemed an unacceptable performance hit. That's no longer the case in the ...


39

IMHO trying to handle null values that you don't expect leads to overly complicated code. If you don't expect null, make it clear by throwing ArgumentNullException. I get really frustrated when people check if the value is null and then try to write some code that doesn't make any sense. The same applies to using SingleOrDefault (or even worse getting ...


36

When should an exception be thrown? On the high level for some people the answer is clear and for some it is more a philosophical question. For many it is something in between and a question of judgment. However when it comes to code, I think that following explanation for the term exception is very helpful: An exception is when a member fails to complete ...


34

As others have said, the math came first. This is why 0 is false and 1 is true. Which math are we talking about? Boolean algebras which date from the mid 1800s, long before digital computers came along. You could also say that the convention came out of propositional logic, which even older than boolean algebras. This is the formalization of a lot of the ...


33

1 - Ignore the error and produce 0 as the result. Logging a warning if possible. That's not a good idea. At all. People will start depending on it and should you ever fix it, you will break a lot of code. 2 - Add NaN as a possible value for numbers, but that raises questions about how to handle NaN values in other areas of the language. You should ...


31

Assuming something will work and displaying an error in case it fails on the remote side is much more user-friendly than blocking the user from doing anything else until there's a response from the server. An email client is actually a great example for this: When I have a list with 5 emails and the top one is selected I expect that when hitting DEL three ...


30

what to show to the user. Should this also be hidden from the user? You show the user what is actionable for them. For example, if you have an error which is caused because of some null pointer exception and more of a bug than user error you don't want full explanation because they can't do anything different. Or should we show this anyway? Or ...


29

I've seen hundreds of bugs that would have been solved faster if someone had written more asserts, and not a single one that would have been solved quicker by writing fewer. [C]ould [too many asserts] potentially be a bad programming practice, in terms of readability and maintainability[?] Readability could be a problem, perhaps - although it's been my ...


29

Exception handling tends to be an expensive way to handle flow control (certainly for C# and Java). The runtime does quite a lot of work when an exception object is constructed - getting the stack trace together, figuring out where the exception is handled and more. All this costs in memory and CPU resources that do not need to be expanded if flow control ...


29

It's simple: you don't need unit testing if you will discard the program after running it once. If this seems excessive to you, consider what the alternative would mean. If there were some size below which unit testing doesn't pay, you would have to keep judging in your mind: "Have I reached the magic size yet? Should I start writing tests?" Now, ...


27

I always think of things like accessing the database server or a web API when thinking of exceptions. You expect the server/web API to work, but in an exceptional case it might not (server is down). A web request might be quick usually, but in exceptional circumstances (high load) it might time out. This is something out of your control. You users' input ...


27

Yes, "fail early" is a very good principle, and this is simply one possible way of implementing it. And in methods that have to return a specific value, there isn't really very much else you can do to fail deliberately - it's either throwing exceptions, or triggering assertions. Exceptions are supposed to signal 'exceptional' conditions, and detecting a ...


25

Yes, there are many. A stack trace can reveal what encryption algorithm you use what some existing paths on your application server are whether you are properly sanitizing input or not how your objects are referenced internally what version and brand of database is behind your front-end ... the list goes on and on. Basically every design decision in a ...


23

Both describe the consistency of an application's behavior, but "robustness" describes an application's response to its input, while "fault-tolerance" describes an application's response to its environment. An app is robust when it can work consistently with inconsistent data. For example: a maps application is robust when it can parse addresses in various ...


21

First of all, I would disagree with this statement: Favour exceptions over error codes This is not always the case: for example, take a look at Objective-C (with the Foundation framework). There the NSError is the preferred way to handle errors, despite the existence of what a Java developer would call true exceptions: @try, @catch, @throw, NSException ...


21

I would just like to note that exceptions and error codes aren't the only way to deal with errors and alternate code paths. Out of the top of the mind, you can have an approach like the one taken by Haskell, where errors can be signaled via abstract data types with multiple constructors (think discriminated enums, or null pointers, but typesafe and with the ...


20

One should avoid throw errors as the way to pass error conditions around in applications. The throw statement should only be used "For this should never happen, crash and burn. Do not recover elegantly in any way" try catch however is used in situation where host objects or ECMAScript may throw errors. Example: var json try { json = JSON.parse(input) ...


20

Some time ago I found a nice post: Why unit testing speeds up development. It can help you answer the question. ...What if the codebase... was provided with a substantial set of unit tests. A set that would say : “if all tests succeed, I guarantee that code still does what it should do” and if a test fails it exactly shows you where some behavior is ...



Only top voted, non community-wiki answers of a minimum length are eligible