I want to write a common error handler which will catch custom errors thrown on purpose at any instance of the code.

When I did `throw new Error(&#39;sample&#39;)` like in the following code

    try {
        throw new Error({&#39;hehe&#39;:&#39;haha&#39;});
        // throw new Error(&#39;hehe&#39;);
    } catch(e) {
    	alert(e);
    	console.log(e);
    }

Log shows in Firefox as `Error: [object Object]` and I couldn’t parse the object.

For the second `throw` the log shows as: `Error: hehe`

Whereas when I did

    try {
        throw ({&#39;hehe&#39;:&#39;haha&#39;});
    } catch(e) {
    	alert(e);
    	console.log(e);
    }

the console showed as: `Object { hehe=&quot;haha&quot;}` in which I was able to access the error properties.

**What is the difference?**

Is the difference as seen in the code? Like string will be just passed as string and object as objects but the syntax will be different?

I haven’t explored throwing error object… I had done only throwing strings.

Is there any other way than the above two mentioned methods?

What is the difference between `throw new Error` and `throw someObject`?

I&#39;m having a debate with a co-worker about throwing exceptions from constructors, and thought I would like some feedback.

Is it OK to throw exceptions from constructors, from a design point of view?

Lets say I&#39;m wrapping a POSIX mutex in a class, it would look something like this:

    class Mutex {
    public:
      Mutex() {
        if (pthread_mutex_init(&amp;mutex_, 0) != 0) {
          throw MutexInitException();
        }
      }
      
      ~Mutex() {
        pthread_mutex_destroy(&amp;mutex_);
      }
      
      void lock() {
        if (pthread_mutex_lock(&amp;mutex_) != 0) {
          throw MutexLockException();
        }
      }
      
      void unlock() {
        if (pthread_mutex_unlock(&amp;mutex_) != 0) {
          throw MutexUnlockException();
        }
      }
      
    private:
      pthread_mutex_t mutex_;
    };

My question is, is this the standard way to do it? Because if the `pthread mutex_init` call fails the mutex object is unusable so throwing an exception ensures that the mutex won&#39;t be created.

Should I rather create a member function init for the Mutex class and call `pthread mutex_init` within which would return a bool based on `pthread mutex_init`&#39;s return? This way I don&#39;t have to use exceptions for such a low level object.

Throwing exceptions from constructors

Why can&#39;t I just throw an `Error` inside the catch callback and let the process handle the error as if it were in any other scope?

If I don&#39;t do `console.log(err)` nothing gets printed out and I know nothing about what happened. The process just ends...

Example:

    function do1() {
        return new Promise(function(resolve, reject) {
            throw new Error(&#39;do1&#39;);
            setTimeout(resolve, 1000)
        });
    }
    
    function do2() {
        return new Promise(function(resolve, reject) {
            setTimeout(function() {
                reject(new Error(&#39;do2&#39;));
            }, 1000)
        });
    }
    
    do1().then(do2).catch(function(err) {
        //console.log(err.stack); // This is the only way to see the stack
        throw err; // This does nothing
    });

If callbacks get executed in the main thread, why the `Error` gets swallowed by a black hole?

Why can I not throw inside a Promise.catch handler?

In C++, you can specify that a function may or may not throw an exception by using an exception specifier. For example:

    void foo() throw(); // guaranteed not to throw an exception
    void bar() throw(int); // may throw an exception of type int
    void baz() throw(...); // may throw an exception of some unspecified type

I&#39;m doubtful about actually using them because of the following:

  1. The compiler doesn&#39;t really enforce exception specifiers in any rigorous way, so the benefits are not great. Ideally, you would like to get a compile error.
  2. If a function violates an exception specifier, I think the standard behaviour is to terminate the program.
  3. In VS.Net, it treats throw(X) as throw(...), so adherence to the standard is not strong.

Do you think exception specifiers should be used?  
Please answer with &quot;yes&quot; or &quot;no&quot; and provide some reasons to justify your answer.

Should I use an exception specifier in C++?

I keep seeing people say that exceptions are slow, but I never see any proof. So, instead of asking if they are, I will ask how do exceptions work behind the scenes, so I can make decisions of when to use them and whether they are slow.

From what I know, exceptions are the same as doing a return bunch of times, except that it also checks after each return whether it needs to do another one or to stop. How does it check when to stop returning? I guess there is a second stack that holds the type of the exception and a stack location, it then does returns until it gets there. I am also guessing that the only time this second stack is touched is on a throw and on each try/catch. AFAICT implementing a similar behaviour with return codes would take the same amount of time. But this is all just a guess, so I want to know what really happens.

How do exceptions really work?

How do exceptions work (behind the scenes) in c++

I picked this up in one of my brief forays to reddit:

&lt;http://www.smallshire.org.uk/sufficientlysmall/2009/07/31/in-c-throw-is-an-expression/&gt;

Basically, the author points out that in C++:

    throw &quot;error&quot;

is an expression. This is actually fairly clearly spelt out in the C++ Standard, both in the main text and the grammar. However, what is not clear (to me at least) is what is the type of the expression? I guessed &quot;`void`&quot;, but a bit of experimenting with g++ 4.4.0 and Comeau yielded this code:

        void f() {
        }
        
        struct S {};
        
        int main() {
        	int x = 1;
        	const char * p1 = x == 1 ? &quot;foo&quot; : throw S();  // 1
        	const char * p2 = x == 1 ? &quot;foo&quot; : f();        // 2
        }

The compilers had no problem with //1 but barfed on //2 because the the types in the conditional operator are different. So the type of a `throw` expression does not seem to be void.

So what is it?

If you answer, please back up your statements with quotes from the Standard. 

----
**This turned out not to be so much about the type of a throw expression as how the conditional operator deals with throw expressions - something I certainly didn&#39;t 
know about before today. Thanks to all who replied, but particularly to David Thornley.**


In C++, if throw is an expression, what is its type?

Is there any difference between `throw()` and `noexcept` other than being checked at runtime and compile time, respectively?

[This Wikipedia C++11 article](http://en.wikipedia.org/wiki/C%2B%2B11#Features_removed_or_deprecated) suggests that the C++03 throw specifiers are deprecated.  
Why so, is `noexcept` capable enough to cover all that at compile time ?

[Note: I checked [this question](https://stackoverflow.com/questions/88573/should-i-use-an-exception-specifier-in-c) and [this article](http://www.gotw.ca/publications/mill22.htm), but couldn&#39;t determine the solid reason for deprecation.]

Difference between C++03 throw() specifier C++11 noexcept

&gt; **Possible Duplicate:**  
&gt; [how to use Java-style throws keyword in C#?](https://stackoverflow.com/questions/3465465/how-to-use-java-style-throws-keyword-in-c)  

&lt;!-- End of automatically inserted text --&gt;

i have a function where an exception occurs
say for example

    private void functionName() throws Exception
    {
       // some code that might throw an exception
    }

thanks!

Is there a throws keyword in C# like in Java?

I am facing the famous &#39;Incorrect syntax&#39; while using a `THROW` statement in a T-SQL stored procedure. I have Googled it and checked the questions on StackOverflow but the solutions proposed (and strangely, accepted) do not work for me.

I am modifying a stored procedure as follows:

&lt;!-- language: lang-sql --&gt;

    ALTER PROCEDURE [dbo].[CONVERT_Q_TO_O]
	    @Q_ID int = NULL,
    	@IDENTITY INT = NULL OUTPUT
    AS
    BEGIN
     	SET NOCOUNT ON;

        DECLARE @EXISTING_RECORD_COUNT [int];

        SELECT
            @EXISTING_RECORD_COUNT = COUNT (*)
	    FROM
		    [dbo].[O]
	    WHERE
		    [Q_ID] = @Q_ID

        IF @EXISTING_RECORD_COUNT = 0
        BEGIN
            -- DO SOME STUFF HERE

            -- RETURN NEW ID
            SELECT @IDENTITY = SCOPE_IDENTITY()
        END
    	ELSE
		BEGIN
			 THROW 99001, &#39;O associated with the given Q Id already exists&#39;, 1;
		END
    END
    GO

When I code this T-SQL I get an error saying 

&gt; Incorrect statement near &#39;THROW&#39;. Expecting CONVERSATION, DIALOG, DISTRIBUTED, or TRANSACTION

All solutions suggest to put a semi-colon either before &#39;THROW&#39; or after &#39;ELSE BEGIN&#39; statements. When I modify the T-SQL I simply get the &quot;***Incorrect statement near &#39;THROW&#39;***&quot; error and can&#39;t seem to find a solution.

Any suggestions?

T-SQL Throw Exception

I have been coding in Java for a while now. But sometimes, I don&#39;t understand when I should throw the exception and when should I catch the exception. I am working on a project in which there are lot of methods. The hierarchy is something like this-

    Method A will call Method B and Method B will call some Method C and Method C will call Method D and Method E.
	
So currently what I am doing is- I am throwing exceptions in all the methods and catching it in Method A and then logging as an error.

But I am not sure whether this will be the right way to do it? Or should I start catching exceptions in all the Methods. So that is why this confusion started in my- When should I catch the Exception vs When should I throw the exceptions. I know it&#39;s a silly question but somehow I am struggling to understand this major concept.

Can someone give me a detailed example of `When to catch the Exception vs When to throw the Exceptions` so that my concepts gets cleared on this? And in my case, should I keep on throwing the exception and then catch it in the main calling Method A?


When to catch the Exception vs When to throw the Exceptions?

[PEP 342 (Coroutines via Enhanced Generators)][1] added a `throw()` method to generator objects, which allows the caller to raise an exception *inside* the generator (as if it was thrown by the `yield` expression).

I am wondering what the use cases for this feature are.


  [1]: http://www.python.org/dev/peps/pep-0342/

What is generator.throw() good for?

At the moment I&#39;m extending my JavaScript project with error handling. The `throw` statement is playing an important role here:

    throw new Error(&quot;text&quot;); // Error: text

However, can I also throw a warning? I tried the following to no avail:

    throw new Warning(&quot;text&quot;); // Warning is not defined

The errors make Chrome&#39;s Developer Tools show a red cross, but how can I make it display a warning icon (yellow exclamation mark)?

&quot;throw new Warning&quot; in JavaScript?

Conventional wisdom says you can only throw objects that extend `Throwable` in Java, but is it possible to disable the bytecode verifier and get Java to compile and run code that throws arbitrary objects - or even primitives?

I looked up the JVM&#39;s [`athrow`][1] and it will pop the first objref on the operand stack; but would it check if said reference points to a `Throwable` at run time?


  [1]: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.athrow

What can you throw in Java?

Can any of you explain what the differences are between `throw`, `throws` and `Throwable` and when to use which?

Exception handling : throw, throws and Throwable

When there is a post-condition, that return value of a method must not be null, what can be done? 

I could do


    assert returnValue != null : &quot;Not acceptable null value&quot;;

but assertions could be turned off!

So is it okay to do


    if(returnValue==null)
          {
               throw new NullPointerException(&quot;return value is null at method AAA&quot;);
          }

?

Or is it better to use a user-defined exception (like NullReturnValueException ) for such a condition?


Is it okay to throw NullPointerException programmatically?

I have a function `foo` that can throw a `bar` exception.

In another function I call `foo` but I have the ability to add some more detail to the `bar` exception if thrown. (I&#39;d rather not pass such information as a parameter to `foo` as it doesn&#39;t really belong there due to the generic nature of that function.)

So I do this in the caller:

    try {
        foo();
    } catch (bar&amp; ex){
        ex.addSomeMoreInformation(...);
        throw;
    }

Will `throw` re-throw the modified exception or do I need to use `throw ex;`? The latter would presumably take a value copy so I&#39;d rather not do that. Would `throw` take a value copy too? I suspect it wouldn&#39;t.

(I&#39;m aware I could verify but I&#39;m concerned about stumbling on an unspecified or undefined construct so would like to know for sure).

Using `throw;` on a modified exception

I found that there are three ways to catch an exception, what are the differences?

1) catch by value;

2) catch by reference;

3) catch by pointer;


I only know that catch by value will invoke two copies of the object, catch by reference will invoke one. So how about catch by pointer? When to use catch by pointer? In addition to throw an object, can I throw a pointer to an object like this?

    class A {}
    
    void f() {
      
      A *p = new A();
            throw p;
    
    
    }

catch exception by pointer in C++

These days, I have been reading a lot the [C++ F.A.Q][1] and especially [this page][2].

Reading through the section I discovered a &quot;technique&quot; that the author calls &quot;exception dispatcher&quot; that allows someone to group all his exception handling in one handy function:

    void handleException()
    {
      try {
        throw; // ?!
      }
      catch (MyException&amp; e) {
        //...code to handle MyException...
      }
      catch (YourException&amp; e) {
        //...code to handle YourException...
      }
    }
     
    void f()
    {
      try {
        //...something that might throw...
      }
      catch (...) {
        handleException();
      }
    }

What bothers me is the single `throw;` statement: if you consider the given example then sure, it is obvious what it does: it rethrows the exception first caught in `f()` and deals with it again.

But what if I call `handleException()` on its own, directly, without doing it from a `catch()` clause ? Is there any specified behavior ?

Additionally for bonus points, is there any other &quot;weird&quot; (probably not the good word) use of `throw` that you know of ?

Thank you.


  [1]: http://www.parashift.com/c++-faq-lite/
  [2]: http://www.parashift.com/c++-faq-lite/exceptions.html

What does a single &quot;throw;&quot; statement do?

&gt; **Possible Duplicate:**  
&gt; [design by contract tests by assert or by exception?](https://stackoverflow.com/questions/117171/design-by-contract-tests-by-assert-or-by-exception)  

&lt;!-- End of automatically inserted text --&gt;

Is there a rule of thumb to follow when deciding to use exceptions instead of asserts (or vice versa). Right now I do only throw if it&#39;s something I think will happen during runtime on the user side (like a socket or file error). Almost everything else I use asserts.

Also, if I were to throw an assert, what is a nice standard object to throw? If I recall correctly there is `std::logic_error`, but is that not a good object to throw? What would I throw for a missing file or unexpected input (such as from the command line instead of a frontend app)?

Exception vs Assert?

The biggest misunderstanding for me in Swift is the `throws` keyword. Consider the following piece of code:

    func myUsefulFunction() throws

We cannot really understand what kind of error it will throw. The only thing we know is that it might throw some error. The only way to understand what the error might be is by looking at the documentation or checking the error at runtime.

But isn&#39;t this against Swift&#39;s nature? Swift has powerful generics and a type system to make the code expressive, yet it feels as if `throws` is exactly opposite because you cannot get anything about the error from looking at the function signature.

Why is that so? Or have I missed something important and mistook the concept?


All Throw Solutions on Gang of Coders

Total of 20 Throw Solutions