Tag Info

Hot answers tagged

192

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() { ...


98

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). ...


64

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 ...


60

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 ...


57

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* ...


57

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: ...


56

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 ...


56

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 ...


56

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.


53

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 ...


40

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 ...


38

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 ...


33

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 ...


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

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, ...


28

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 ...


26

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 ...


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 ...


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

Exceptions should be exceptional: It's expected that the user may input invalid data, so this isn't an exceptional case On that argument: It's expected that a file may not exist, so that isn't an exceptional case. It's expected that the connection to the server may be lost, so that isn't an exceptional case It's expected that the configuration file ...


20

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

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 ...


19

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 ...


17

I'll share the way I ended up doing this, that was part of the original question. First, the problems I encountered: With customErrors on (i.e. in production) the global HandleError attribute swallows exceptions and renders your error view, but then you can't log it with an addon tool like elmah, since elmah never sees it. You could log it in your view I ...


17

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) ...


17

I thought this had to do with the "inheritance" from electronics, and also boolean algebra, where 0 = off, negative, no, false 1 = on, positive, yes, true strcmp returns 0 when strings are equal has to do with its implementation, since what it actually does is to calculate the "distance" between the two strings. That 0 also happens to be a looked at as ...


16

The Stack Overflow not found page is quite a good example. It states: We couldn't find the page you requested. Neutral in tone so it's not implying that the user is at fault. It then has links to the search page, recent questions and popular tags. It also has a link to allow the user to contact the team. So you need to do the following: Add a link ...


16

The habit of checking for null to my experience comes from former C or C++ developers, in those languages you have a good chance of hiding a severe error when not checking for NULL. As you know, in Java or C# things are different, using a null ref without checking for null will cause an exception, thus the error will not be secretly hidden as long as you ...


16

According to Kent Beck in his answer to Stack Overflow question How deep are your unit tests?, you should test the code that you tend to get wrong. If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it.



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