exception-handling

问题 Consider the following C++ program struct str { int mem; str() try :mem(0) { throw 0; } catch(...) { } }; int main() { str inst; } The catch block works, i.e. the control reaches it, and then the program crashes. I can't understand what's wrong with it. 回答1: Once the control reaches the end of the catch block of function-try-block of a constructor, the exception is automatically rethrown. As you don't catch it further in main(), terminate() is called. Here is an interesting reading: http:/

问题 I am original Java developer, for me, checked Exception in Java is obviously/easy enough for me to decide to catch or throw it to the caller to handle later. Then it comes Python, there is no checked exception, so conceptually, nothing forces you to handle anything(In my experience, you don't even know what exceptions are potentially thrown without checking the document). I've been hearing quite a lot from Python guys that, in Python, sometimes you better just let it fail at runtime instead

问题 I am using a SimpleMappingExceptionResolver that sends all exceptions to an view where it is nicely rendered. That works except one case: If the user requests a page, and then send and "Abort" ( I don't know exactly how that works, but I noticed that if I click an HTTP post form submit button very fast and often the Firefox 7 somehow notify the server that it is not longer interested in the result. ) Then the Tomcat 6 rises an ClientAbortException when one try to render the page, or write the

问题 I have a custom exception filter that I'm using to catch a custom exception that I wrote but for some reason when I throw my exception, it's not ever getting to the filter. Instead I just get an error that my exception was not handled by user code. Can anyone please provide some advice/assistance as to how I should have this set up? Relevant code is below: // controller [CustomExceptionFilter] public class SomeController : Controller { public SomeController() { } public ActionResult Index() {

问题 Is this considered good programming practice in C++: try { // some code } catch(someException) { // do something } catch (...) { // left empty <-- Good Practice??? } 回答1: No! That is a terrible practice! Just about the only time you should catch (...) and not rethrow the exception would be in main() to catch any otherwise unhandled exceptions and to display or log an error before exiting. If you catch (...) , you have absolutely no idea what exception was thrown, and thus you can't know

问题 I am raising some application errors from PL/SQL procedures. I am setting some messages for instance, RAISE_APPLICATION_ERROR(-20001, 'message'); Is there any way, I can display 'message' in exception section in catch block of java program from which I called this procedure? 回答1: If you're doing catch (Exception e) , message should be available from e.getMessage() . If you're doing catch (SQLException e) (or whatever the exception type is for your data access package) message should still be

问题 I am currently writing a windows service that runs entirely in the background and does something every day. My idea is that the service should be very stable so if something goes wrong it should not stop but try it next day again and of course log the exception. Can you suggest me any best practice how to make truly stable windows services? I have read the article of Scott Hanselman of exception handling best practice where he writes that there are only few cases when you should swallow an

问题 Is it safe (correct) to simply return from method's and do nothing if context is null? currently I'm doing this when ever I need context from fragment. Context context = getContext(); if(context == null) return; My question is too stupid and obvious but I'm still not sure if this is correct. if its necessary or not. (maybe I should log warnings?) I do this check in onCreateView , onViewCreated , when getting context from itemView in view holders and inside view click listeners when ever

问题 (edit: this question is about BB specifically, because of the strange way it optimises exceptions. I am comfortable with normal exception handling patterns in J2SE, but BB does not behave as per normal. Specifically in this case, BB discards the error type, and message, and how BB devs try to deal with this issue, or if they ignore it.) I would like to implement some form of custom global error handling in my BB app. Specifically to try to handle any other exceptions that were not caught by

问题 I am new to WPF, I am using VS2010 beta2, .NET 4.0. Throw new Exception("test") in my code simply swallows exception and application does not crash. This is not what I expect, I want the application to crash if unhandled exception occurs. Is there a simple way to achieve this? Also, neither Application.DispatcherUnhandledException nor AppDomain.UnhandledException is executed. It is probably because all code is executed as part of the data binding (I am using MVVM pattern and exception is