Tag Info

New answers tagged

4

You should prefer programmatic checks to exceptions whenever you can. An exception is exceptional, you should only throw them where a condition arises that you cannot correct. And please, don't use them for control flow. It's fine to throw an exception in your cache GET, but ONLY if you also provide calling code with a way to check beforehand if the ...


0

Generally speaking an exception is called an exception because it should be an exception. Throwing an exception will (as far as I know, correct me if I'm wrong) invalidate the whole command-pipeline and are therefore to be considered to be very slow. Exceptions will however give you the benefit of not having to perform any null-checks AND allow you to ...


0

If I came across a method called AddRecord, I'd conclude - from it's name - that it was a statement, not a yes/no question. It's not asking me if I want to add a record; I'm telling it to do so. Therefore I'd expect one of two possible return types, depending on whether I'm thinking OO or functional: void - I've commanded it to do something. If there's a ...


1

You're right that it's generally best to let other code's exceptions propagate through yours unimpeded. Where I work, this is called being "exception-agnostic". Now for the hard part. The return values of your functions are part of your public API. Having a return value that doesn't mean anything is a lot like having a method that doesn't do anything when ...


3

In my opinion, methods should either return a value or have a side effect, but not both. In this answer to another question the author quotes the source of that practice. In your examples, you handle a situation in which you try to add an element to a collection that could be or could not be initialized. My suggestion is that you either throw an exception ...


6

It seems that you have misunderstood what is meant when people say that you shouldn't use exceptions for flow-control in your program. Throwing an exception and catching that exception elsewhere in your program changes the control flow of the program. In that way, exception handling is a flow-control construct, just like a while loop or a goto statement. ...


1

There are a lot of ways to deal with this. Here's just two ideas: Wrap your try-catch into a method with boolean return type, indicating whether the ExecuteCode() succeeded. The control flow is decided on the usage site then, where you show the error message and go back on failure. It's similar to you second version, but instead of directly modifying a ...


1

First of all, you should copy the reference of action delegate instance before invoking it to prevent threading issues, like this: private void ExecutionAction(Action action) { var handler = action; if (handler == null) { return; } try { handler(); } catch (System.Data.SqlTypes.SqlTypeException e) { ...


2

Yes, in some implementations of futures: in both cases the (single) thread of execution moves up the call stack on await/throw, and both can be seen as a form of condition, as in the Common Lisp Condition System, and async on a function definition is analogous to throws, specifying the kind of condition it may signal. However, the closer analogy is that ...


1

The answer depends on the responsibilities of your wrapping class. If all it does is encapsulate your connection settings for convenience, then simply letting PDOException pass through is preferable. If your wrapper has more responsibilities such as encapsulating certain queries or connection pooling, you may want to develop an exception or two for this ...


2

You shouldn't catch the PDOException at all. Now, you should have some sort of last resort exception handler that catches all exceptions and logs them. PDOExceptions should be caught there. But you shouldn't catch them anywhere else. In my understanding, PDOException indicates either that something has gone very wrong with the connection to the database, ...


1

I would argue its impossible to handle all exceptions the same way. I think you should let it propagate back to the calling code as it ultimately knows how it should handle the exceptional situation. Just to think of a (maybe weird) example. Imagine you have an blog. An each hour you query the database for new articles. But luck isn't with you and your ...


0

Its a reasonably common practice - C programs (and other systems, eg errno) often to store the last error in a location so you can pick the details out if a function returned an error code. There's no reason why you can't do the same. However, if you do this you have to take a few things into consideration. Threads are very important, each error info must ...



Top 50 recent answers are included