The short answer is: nowhere. It is a relic of the past, where Microsoft intended developers to inherit all their custom exceptions from ApplicationException. Shortly after, they changed their mind and advised that custom exceptions should derive from the base Exception class. See Best Practices for Handling Exceptions on MSDN. One of the more widely … Read more
I have always thought, that’s similar to the following scenario: “A man gets shot. He holds his breath and has enough strength to take a bus. 10 miles later the man gets off of the bus, walks a couple of blocks and dies.” When the police gets to the body, they don’t have a clue … Read more
The Thread interrupt mechanism is the preferred way to get a (cooperating) thread to respond a request to stop what it is doing. Any thread (including the thread itself I think) could call interrupt() on a Thread. In practice, the normal use-cases for interrupt() involve some kind of framework or manager telling some worker thread … Read more
Guidelines that have helped me in the past include: Throw exceptions when the method cannot handle the exception, and more importantly, should be handled by the caller. A good example of this happens to present in the Servlet API – doGet() and doPost() throw ServletException or IOException in certain circumstances where the request could not … Read more
In Java, as you may know, exceptions can be categorized into two: One that needs the throws clause or must be handled if you don’t specify one and another one that doesn’t. Now, see the following figure: In Java, you can throw anything that extends the Throwable class. However, you don’t need to specify a … Read more
I use [NSException raise:format:] as follows: [NSException raise:@”Invalid foo value” format:@”foo of %d is invalid”, foo];
A few more bits … You absolutely should have a centralized exception handling policy in place. This can be as simple as wrapping Main() in a try/catch, failing fast with a graceful error message to the user. This is the “last resort” exception handler. Preemptive checks are always correct if feasible, but not always perfect. … Read more
Yes he is correct. As you can see in the Javadoc, SQLDataException is a subclass of SQLException. Therefore, your answer is wrong, since it would create a block of unreachable code in the second catch. In Java, this code would not even compile. In other languages (e.g. python) such code would create a subtle bug, … Read more
You can return a tuple of record and exception in the parsefunc and let the consumer function decide what to do with the exception: import random def get_record(line): num = random.randint(0, 3) if num == 3: raise Exception(“3 means danger”) return line def parsefunc(stream): for line in stream: try: rec = get_record(line) except Exception as … Read more
The finally block (nearly) always executes, whether or not there was an exception. I say nearly because there are a few cases where finally isn’t guaranteed to be called: If there is an infinite loop or deadlock in your code so that the execution remains inside the try or catch blocks then the finally block … Read more