Talk:Exceptions/Catch an exception thrown in a nested call: Difference between revisions

From Rosetta Code
Content added Content deleted
Line 19: Line 19:
==R code doesn't catch anything?==
==R code doesn't catch anything?==
Function foo should catch the first exception raised, but fail to catch the second exception. I don't know R, but I can't see where function foo catches one exception but not the other? --[[User:Paddy3118|Paddy3118]] 17:09, 23 November 2009 (UTC)
Function foo should catch the first exception raised, but fail to catch the second exception. I don't know R, but I can't see where function foo catches one exception but not the other? --[[User:Paddy3118|Paddy3118]] 17:09, 23 November 2009 (UTC)

== incomplete task description ==

This task does not specify that the second instance of foo should be independently wrapped by a different catch instance than the first. It probably should explicitly specify this.

Consider this alternative implementation which fits a literal reading of the task specification:

try {
foo(1);
foo(2);
} catch (U0) {
}

It is clear from reading the existing implementations that this was not intended, but a casual reading of the specification suggests this implementation.

Revision as of 21:40, 28 January 2010

As opposed to what?

Isn't "through nested calls" the normal behavior for exceptions? What language's exceptions doesn't work through nested calls? Isn't this basically the same as Exceptions? --Spoon! 07:01, 7 March 2009 (UTC)

The devils in the detail. For example, some languages might have to annotate each function with details of what exceptions go through them. This example will also point out how one particular exception is caught and not another, that must nevertheless be thrown; and finally the task asks that you describe what happens when a user exception is not caught, languages may give differing amounts of information on the uncaught exception.
I did read exceptions, but thought that there was room for another task to bring out other, specific aspects, as well as try and have the examples implement the same thing rather than exceptions 'show me what you can do' approach. (Which is fine, but different).
After my explanation, do you think the task should be deleted? --Paddy3118 12:50, 7 March 2009 (UTC)

Ada example and un-caught exception

The Ada example catches both exceptions at some level rather than leaving one un-caught and explaining the consequences. Could someone make the change? --Paddy3118 11:54, 22 March 2009 (UTC)

Fixed --Dmitry-kazakov 15:43, 22 March 2009 (UTC)

A question on Java

If you changed public static void foo() throws U1 to remove the reference to it throwing U1, would that always be a compile time error? --Paddy3118 05:14, 1 May 2009 (UTC)

Yes. You could change it to throws Exception, but then you would have to surround all calls to the function with a try block which would catch(Exception e), which would then catch the U1 Exception and fail to meet the task requirements. I'm not sure if Java could do this task (or if it would even be good practice in any language). --Mwn3d 05:47, 1 May 2009 (UTC)
Also throws Exception and catch(Exception e) will both usually make me cringe a bit. Try to avoid them :). --Mwn3d 06:20, 1 May 2009 (UTC)

R code doesn't catch anything?

Function foo should catch the first exception raised, but fail to catch the second exception. I don't know R, but I can't see where function foo catches one exception but not the other? --Paddy3118 17:09, 23 November 2009 (UTC)

incomplete task description

This task does not specify that the second instance of foo should be independently wrapped by a different catch instance than the first. It probably should explicitly specify this.

Consider this alternative implementation which fits a literal reading of the task specification:

  try {
     foo(1);
     foo(2);
  } catch (U0) {
  }

It is clear from reading the existing implementations that this was not intended, but a casual reading of the specification suggests this implementation.