exception-handling

Why is try {…} finally {…} good; try {…} catch{} bad?

旧巷老猫 提交于 2019-12-17 05:33:30
问题 I have seen people say that it is bad form to use catch with no arguments, especially if that catch doesn't do anything: StreamReader reader=new StreamReader("myfile.txt"); try { int i = 5 / 0; } catch // No args, so it will catch any exception {} reader.Close(); However, this is considered good form: StreamReader reader=new StreamReader("myfile.txt"); try { int i = 5 / 0; } finally // Will execute despite any exception { reader.Close(); } As far as I can tell, the only difference between

Why is try {…} finally {…} good; try {…} catch{} bad?

ⅰ亾dé卋堺 提交于 2019-12-17 05:33:19
问题 I have seen people say that it is bad form to use catch with no arguments, especially if that catch doesn't do anything: StreamReader reader=new StreamReader("myfile.txt"); try { int i = 5 / 0; } catch // No args, so it will catch any exception {} reader.Close(); However, this is considered good form: StreamReader reader=new StreamReader("myfile.txt"); try { int i = 5 / 0; } finally // Will execute despite any exception { reader.Close(); } As far as I can tell, the only difference between

Retry a task multiple times based on user input in case of an exception in task

瘦欲@ 提交于 2019-12-17 05:03:58
问题 All the service calls in my application are implemented as tasks.When ever a task is faulted ,I need to present the user with a dialog box to retry the last operation failed.If the user chooses retry the program should retry the task ,else the execution of the program should continue after logging the exception.Any one has got a high level idea on how to implement this functionality ? 回答1: UPDATE 5/2017 C# 6 exception filters make the catch clause a lot simpler : private static async Task<T>

Difference between using Throwable and Exception in a try catch

China☆狼群 提交于 2019-12-17 04:37:21
问题 Sometimes I see try { } catch(Throwable e) { } And sometimes try { } catch(Exception e) { } What is the difference 回答1: By catching Throwable it includes things that subclass Error . You should generally not do that, except perhaps at the very highest "catch all" level of a thread where you want to log or otherwise handle absolutely everything that can go wrong. It would be more typical in a framework type application (for example an application server or a testing framework) where it can be

UnobservedTaskException being throw but it is handled by a TaskScheduler.UnobservedTaskException handler and a continuations OnlyOnFaulted handler [duplicate]

半城伤御伤魂 提交于 2019-12-17 04:35:29
问题 This question already has answers here : How to handle all unhandled exceptions when using Task Parallel Library? (3 answers) Closed 10 months ago . I having problems with TPL programming. Im getting UnobservedTaskException, im using @h4165f8ghd4f854d6f8h solution on [ http://stackoverflow.com/questions/7883052/a-tasks-exceptions-were-not-observed-either-by-waiting-on-the-task-or-accessi/11830087#11830087 ] to handle exceptions but still getting UnobservedTaskException. I put the following

Scope of exception object in C++

让人想犯罪 __ 提交于 2019-12-17 04:28:45
问题 What is the scope of the exception object in C++? does it go out of scope as soon as catch handler is executed? Also, if I create an unnamed exception object and throw it, then while catching that exception does it matter if I catch it by const reference or a non-const reference? 回答1: When a throw expression is evaluated, an exception object is initialized from the value of the expression. The exception object which is thrown gets its type from the static type of the throw expression ignoring

Conditions when finally does not execute in a .net try..finally block

…衆ロ難τιáo~ 提交于 2019-12-17 04:22:53
问题 Basically I've heard that certain conditions will cause .net to blow past the finally block. Does anyone know what those conditions are? 回答1: Two possibilities: StackOverflowException ExecutionEngineException The finally block will not be executed when there's a StackOverflowException since there's no room on the stack to even execute any more code. It will also not be called when there's an ExecutionEngineException , which may arise from a call to Environment.FailFast() . 回答2: Unless the CLR

Disable assertions in Python

核能气质少年 提交于 2019-12-17 04:21:28
问题 How do I disable assertions in Python? That is, if an assertion fails, I don't want it to throw an AssertionError , but to keep going. How do I do that? 回答1: How do I disable assertions in Python? There are multiple approaches that affect a single process, the environment, or a single line of code. I demonstrate each. For the whole process Using the -O flag (capital O) disables all assert statements in a process. For example: $ python -Oc "assert False" $ python -c "assert False" Traceback

What happens if a finally block throws an exception?

一世执手 提交于 2019-12-17 04:11:19
问题 If a finally block throws an exception, what exactly happens? Specifically, what happens if the exception is thrown midway through a finally block. Do the rest of statements (after) in this block get invoked? I am aware that exceptions will propagate upwards. 回答1: If a finally block throws an exception what exactly happens ? That exception propagates out and up, and will (can) be handled at a higher level. Your finally block will not be completed beyond the point where the exception is thrown

Why is exception.printStackTrace() considered bad practice?

回眸只為那壹抹淺笑 提交于 2019-12-17 02:34:08
问题 There is a lot of material out there which suggests that printing the stack trace of an exception is bad practice. E.g. from the RegexpSingleline check in Checkstyle: This check can be used [...] to find common bad practice such as calling ex.printStacktrace() However, I'm struggling to find anywhere which gives a valid reason why since surely the stack trace is very useful in tracking down what caused the exception. Things that I am aware of: A stack trace should never be visible to end