You should catch the exception when you are in the method that knows what to do. For example, forget about how it actually works for the moment, let’s say you are writing a library for opening and reading files. So you have a class, say: public class FileInputStream extends InputStream { public FileInputStream(String filename) { … Read more
throws : Used when writing methods, to declare that the method in question throws the specified (checked) exception. As opposed to checked exceptions, runtime exceptions (NullPointerExceptions etc) may be thrown without having the method declare throws NullPointerException. throw: Instruction to actually throw the exception. (Or more specifically, the Throwable). The throw keyword is followed by … Read more
Instead of guessing, I decided to actually look at the generated code with a small piece of C++ code and a somewhat old Linux install. class MyException { public: MyException() { } ~MyException() { } }; void my_throwing_function(bool throwit) { if (throwit) throw MyException(); } void another_function(); void log(unsigned count); void my_catching_function() { log(0); try … Read more
As others have explained, the “black hole” is because throwing inside a .catch continues the chain with a rejected promise, and you have no more catches, leading to an unterminated chain, which swallows errors (bad!) Add one more catch to see what’s happening: do1().then(do2).catch(function(err) { //console.log(err.stack); // This is the only way to see the … Read more
The recommended way is to throw by value and catch by reference. Your example code throws a pointer, which is a bad idea since you would have to manage memory at the catch site. If you really feel you should throw a pointer, use a smart pointer such as shared_ptr. Anyway, Herb Sutter and Alexei … Read more
No. Here are several examples why: Template code is impossible to write with exception specifications, template<class T> void f( T k ) { T x( k ); x.x(); } The copies might throw, the parameter passing might throw, and x() might throw some unknown exception. Exception-specifications tend to prohibit extensibility. virtual void open() throw( FileNotFound … Read more
Yes, throwing an exception from the failed constructor is the standard way of doing this. Read this FAQ about Handling a constructor that fails for more information. Having a init() method will also work, but everybody who creates the object of mutex has to remember that init() has to be called. I feel it goes … Read more