try-catch

问题 What is the difference between: catch { MessageBox.Show("Error."); } and: catch (Exception ex) { MessageBox.Show("Error."); //we never use ex, so is it better to use catch without arguments? } 回答1: As of .NET 2, if you don't tweak the configuration? Nothing. Before then, or with some config tweak I can't remember precisely, there was the possibility of an exception being thrown from unmanaged code which didn't get converted into an Exception -compatible object. Note that there's another

问题 This question already has answers here : Weird Try-Except-Else-Finally behavior with Return statements (2 answers) Closed 6 years ago . There is the interesting code below: def func1(): try: return 1 finally: return 2 def func2(): try: raise ValueError() except: return 1 finally: return 3 func1() func2() Could please somebody explain, what results will return these two functions and explain why, i.e. describe the order of the execution 回答1: From the Python documentation A finally clause is

问题 I have this code try { //AN EXCEPTION IS GENERATED HERE!!! } catch { SqlService.RollbackTransaction(); throw; } Code above is called in this code try { //HERE IS CALLED THE METHOD THAT CONTAINS THE CODE ABOVE } catch (Exception ex) { HandleException(ex); } The exception passed as parameter to the method "HandleException" contains the line number of the "throw" line in the stack trace instead of the real line where the exception was generated. Anyone knows why this could be happening? EDIT1 Ok

问题 I just found in a project: try { myLabel.Text = school.SchoolName; } catch { myPanel.Visible = false; } I want to talk to the developer than wrote this, saying that incurring the null exception (because school might theoretically be null, not myLabel ) would virtually make the computer beep three times and sleep for two seconds. However, I wonder if I'm misremembering the rule about that. Obviously, this isn't the intended use for try/catch, but is this bad because it defies intention, or bad

问题 Consider the following excerpt from ECMA-262 v5.1 (which I recently saw in this question): A Lexical Environment is a specification type used to define the association of Identifiers to specific variables and functions based upon the lexical nesting structure of ECMAScript code. A Lexical Environment consists of an Environment Record and a possibly null reference to an outer Lexical Environment. Usually a Lexical Environment is associated with some specific syntactic structure of ECMAScript

问题 Considering you have code like this: doSomething() // this method may throw a checked a exception //do some assignements calculations doAnotherThing() //this method may also throw the same type of checked exception //more calls to methods and calculations, all throwing the same kind of exceptions. Now I know, there is in fact a performance hit when constructing the exception, specifically unwinding the stack. And I have also read several articles pointing to a slight performance hit when

问题 I have an example function below that reads in a date as a string and returns it as a date object. If it reads a string that it cannot convert to a date, it returns an error. testFunction <- function (date_in) { return(as.Date(date_in)) } testFunction("2010-04-06") # this works fine testFunction("foo") # this returns an error Now, I want to use lapply and apply this function over a list of dates: dates1 = c("2010-04-06", "2010-04-07", "2010-04-08") lapply(dates1, testFunction) # this works

问题 Is there any overhead in Java for using a try/catch block, as opposed to an if block (assuming that the enclosed code otherwise does not request so)? For example, take the following two simple implementations of a "safe trim" method for strings: public String tryTrim(String raw) { try { return raw.trim(); } catch (Exception e) { } return null; } public String ifTrim(String raw) { if (raw == null) { return null; } return raw.trim(); } If the raw input is only rarely null , is there any

问题 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

问题 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