Tag Info

New answers tagged

0

In my view custom exceptions make sense only in 2 cases: 1) you're developing an Api 2) you use it in your code to recover from a failure. In any other scenario, built in exceptions should be sufficient. In your case you could use InvalidArgumentException


1

In general Subclassing exceptions is a good idea to group the exceptions into the families or groupings that they belong to. It also allows client code the opportunity to handle exceptions based on specific errors or more generally. I usually divide the tree somewhere near the root between the logical and runtime errors (e.g. in C++ the std::runtime_error ...


1

I think that the requirement not to change the behavior of the legacy application is pretty restrictive. Further, I completely agree with you that the right thing to do is just throw the Exception and catch it where it needs to be caught, by the UI. That said, given the requirement not to change the behavior, I think your solution is a tolerable compromise, ...


1

How about a different change to the methods: Gut all the existing methods, move the code into new methods. The existing methods contain only the exception-swallower and otherwise call the new methods to do the work. This leaves the legacy form that you can call if you want it swallowed or the new form if you want it to throw when it should throw. This ...


0

I think your best bet is to simply use the catch block to log the exception and any other information that will help you trace the error, including a stack trace. This satisfies your callers, who don't have to change their method signatures, and further satisfies the developers, who now have a way to diagnose problems involving thrown exceptions.


0

Been there. What I did was as follows: In the file repository class that implements FooRepository: try{ // try to store } catch (IOException e) { throw new CouldntStoreFooException(e.getLocalizedMessage()); } try{ // try to retrieve } catch (IOException e) { throw new ...


0

Your approach is correct and if you need that your repository client could differentiate between repository exceptions, maybe for showing different kinds of errors, you could also create a tree of Repository Exceptions (always inheriting RuntimeException) like Spring does. public class IntegrityConstraintViolationextends RepositoryException { } public ...


3

Your solution is correct: repository should throw a generic RepositoryException-type to signal that something went wrong. You wrap the actual exception in that RepositoryException so your logging can get access to the data it needs and your consumers can trap the generic exception and handle it somewhere down the line. Wrapping the actual exceptions hides ...


1

I think your strategy is correct (and I accept opinions may vary as to "best"). The client should not care if the underlying repository is a file or a DB server, they care that the commit failed - they need to know that first and handle it. Following on from that, if they wish (e.g. require user intervention or detailed logging) try deal with the underlying ...


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


1

A class is responsible for its own state. So validate to the extent that it keeps or puts things in an acceptable state. If a module will be used in a wrong way, we want to throw exception immediately instead of any unpredictable behavior. No, don't throw an exception, instead deliver predictable behavior. Corollary to state responsibility is to make ...


1

There are major differences between throwing exceptions and returning error objects, in particular, exceptions create many new code-flow paths which are not explicitly visible in the source code, callers have no idea what kinds of errors they can expect, they propagate automatically, and they make the code much less verbose and easier to read and write. ...


1

Well, it could conceivably be useful. If the function shouldn't have used exceptions anyway. But your type is all wrong: You have to allocate the exception dynamically (or at least allow for it being allocated dynamically) to allow for returning a sub-type. Avoid stacking mutually exclusive optionals on top of each other, that just wastes space. And ...


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


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



Top 50 recent answers are included