Tag Info

New answers tagged

0

There are three general ways of signaling error condions to the caller of methods -- exceptions, error codes, mutating error object that is passed in as a parameter. The problem with error codes is that if the method is a function, they only work well if you can fit them within the natural return values (ie negative indexes) or the language (such as ...


7

Yes, throwing exceptions is a good idea. Throw them early, throw them often, throw them eagerly. I know there's an "exceptions vs. assertions" debate, with some kinds of exceptional behavior (specifically, the ones thought to reflect programming errors) handled by assertions that can be "compiled out" for runtime rather than debugging/testing builds. But ...


1

In general, yes, it is a good idea to "fail early". However, in your specific example, the explicit IllegalArgumentException does not provide a significant improvement over a NullReferenceException - because both objects operated upon are delivered as arguments to the function already. But lets look at a slightly different example. class PersonCalculator ...


1

Failing as soon as possible is great when debugging an application. I remember a particular segmentation fault in a legacy C++ program : the place where the bug was detected had nothing to do with the place where it was introduced (the null pointer was happily moved from one place to another in memory before it finally caused a problem). Stack traces cannot ...


-2

In your example function, I would prefer you did no checks and just allow the NullReferenceException to happen. For one, it makes no sense to be passing a null there anyway, so I'll figure out the problem immediately based on the throwing of a NullReferenceException. Two, is that if every function is throwing slightly different exceptions based on what ...


1

As far as I know different programmers prefer one solution or the other. The first solution is usually preferred because it is more concise, in particular, you do not have to check the same condition again and again in different functions. I find the second solution, e.g. public void registerPerson(Person person){ if(person == null) throw new ...


0

Not in the examples you give. As you say, throwing explicitly isn't gaining you much when you're going to get an exception shortly thereafter. Many will argue that having the explicit exception with a good message is better, though I don't agree. In pre-released scenarios, the stack trace is good enough. In post-release scenarios, the call site often can ...


23

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


2

I would recommend to use a common error code file, exactly like @GlenH7, but I would also recommend to write self-contained functions or modules which don't need the global error file at all. For example, if a `connect´ function can just fail (or not), return a boolean indicator. The caller of that function may decide to map the boolean return value to a ...


4

we would define that code in the .h file where the function prototype is declared. I would recommend against this as you don't have anything to reduce the space for potential numbering conflicts. Instead, use a common header file providing error codes for both your client and server applications. As an alternative, the client file can simply be a ...


2

My two cents. First, most async models I've seen in libraries tend to make me frustrated. Everybody seems to have their own slightly different brand of async, and many of those interfaces are not good. As such, I tend to like libraries that keep everything synchronous. Note that callbacks can still be good. But keep all the logic on one thread; the ...


3

it looks to me like the concept is:- ' letting a process run assuming its not properly developed. Error conditions are often beyond the control of the programmer at the level where they occur. Exception handling is one way to handle problems that come up. For example, consider a purchasing account that lets a user order products and pay for them out of ...



Top 50 recent answers are included