Talk:Exception handling

Continuable Exceptions?

Would whoever wrote the section on continuable exceptions please provide a code example? It sounds like you are talking about a special language construct that I don't think exists in any language. People do sometimes talk about "continuable exceptions" but they are just talking about exceptions that they can ignore or resolve as opposed to those that lead to process termination.Firefight (talk) 14:25, 31 January 2009 (UTC)

Visual Basic 6 supports resuming from exceptions; in other languages (such as Java or .NET languages) exceptions as provided by the language are not resumable, but resumable exceptions are implemented with events or another forms of callback. E.g. the .NET System.Windows.Forms library uses them a lot - see e.g. this StackOverflow question. Rp (talk) 09:50, 7 March 2012 (UTC)

Objective-C?

I bet there are no language constructions for handling exceptions in bare Objective-C.

At least Curly bracket programming language now claims it has @try, @catch, @finally. --TuukkaH 09:39, 7 January 2006 (UTC)

OReilly's 'Objective-C. Pocket Reference' doesn't mention this construct. --Pdemb 13:55, 7 January 2006 (UTC)

Ok, they seem to be a new thing. The words starting with @ are "compiler directives" and the ones here are only supported by gcc >= 3.3 in programs compiled to be run in the "Objective C runtime" of Apple MacOS X >= 10.3. See [1] and [2]. Seems like Apple defines Objective C these days... OTOH, the second reference shows how exception handling has been written before, so it's just the syntax that is new. --TuukkaH 15:19, 7 January 2006 (UTC)

GCC's manpage does. Dysprosia 12:18, 8 January 2006 (UTC)

Could be, though GCC adds for example trampolines to C, and trampolines don't belong to C standard. --Pdemb 18:25, 8 January 2006 (UTC).

Clarification

That is, if function f contains a handler H for exception E, calls function g, which in turn calls function h, and an exception E occurs in h, then functions h and g will be terminated and H in f will handle E. Huh? Please can somebody try to make this sentence a bit clearer?

(Un)Checked Exceptions

Very nice guys! Perhaps we should include a bit about checked and unchecked exceptions (they exist in Java at least; they're probably in other high-level languages, if not all languages). --pie4all88 00:42, 30 Nov 2004 (UTC)

Apart from CLU (Liskov & al) I'm not sure. Could take inspiration from http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_d%27exceptions. I wrote it so I'm quite confident it's not all bullshit :) Aurelien

I regret I don't really understand French. But thanks a lot for a pointer to CLU, very few people and articles seem to consider it! Looking at [3] it's not exactly what Java has, but technically close to it. --TuukkaH 22:05, 6 January 2006 (UTC)

• /Definition of unchecked exceptions: February 25 2006

I had had enough of declaring that methods throw this that or the other thing to the point that I started deriving all my custom exceptions from java.lang.error, for which declaring throws isn't required.

I agree - we need some info about unchecked exceptions. My reading of the Java specs [4] is that unchecked exceptions come from a different class hierarchy, and the compiler does not complain about not declaring them. CDaMama 02:41, 12 January 2007 (UTC)

Porting the fr.wiki version

The French version of this article [5] seems to be much better than the EN one. Any volunteers for porting? :) CDaMama 02:41, 12 January 2007 (UTC)

Exceptions and signals

It is not clear how exceptions make signals obsolete -- signals are mostly used for IPC, i.e., kill(pid_t pid, int sig) is used to send signals to different process. Probably exceptions are `better' than longjmp, but even this is not obvious.

Exceptions do not make signals obsolete, they are quite different. Signals are a means of inter process communication while exceptions are confined to one process or thread (only Erlang and Oz have something wrt exceptions propagation between processes and it does not work like signals). Exceptions are thus synchronous, signals are asynchronous (ie the processes ought to be prepared to receive signals at any moment, thus building truly atomic program parts somewhat is very complicated if not impossible ; there is no such problem with exceptions).Aurelien 19:43, 30 October 2005 (UTC)

---

the difference with systems that do not use exceptions to signal improper program executions is that with proper exception handling, the erroneous condition may be pointed precisely, whereas otherwise it is often detected later, making debugging difficult.

this line is very long and hard to read/understand --Alex Curvers 08:20, 31 December 2005 (UTC)

Pros and cons

"IMHO, the previous is not true at all in Java."

Who is the "I", and why is that person's opinion so important that it should be listed with the editorial voice instead of as an opinion from a reference?

Common knowledge ;-) When I edited the section, I tried to make it more neutral and third-person. Hope you like it better! --TuukkaH 22:05, 6 January 2006 (UTC)

Rules of thumb: Exceptions in Java

I have found the following rules to be helpful in guiding me in the use of exceptions:

Business logic level exceptions are checked, low level exceptions and programmer errors are not. When using the low level java api, which throw checked exceptions all over the place, within a method exposed to the business logic, catch the exception and wrap it in a runtime (not checked) exception (eg 'FileNotFoundException' is wrapped in 'WrappedRuntimeException'), unless you assume the cause can be handled/caused by client code in which case wrap it up in a checked exception (eg 'FileNotFoundException' wrapped in a 'InvalidUserInputException' ).

This way one does not end up using the top level 'throws Exception' everywhere making the whole exception handling idea meaningless (may as well make it unchecked).

Some folks suggest to use un-checked exceptions everywhere (even business logic error), but then there is no way to easily document these (javadcos aren't created for them) and does not make use of the automatic checking provided by the compiler

Bertvanbrakel 23:20, 26 October 2006 (UTC)

Reorganization of articles

I just merged exception (computing) here. User:Derek farn proposed that the merge result should be named Exception (computing) though. I think that Exception handling is fine as we have a redirect here, and Exception handling doesn't need parentheses, and an unhandled exception would be a crash anyway.

More along the lines of Wikipedia:Wikipedia is not a dictionary, could we separate the different concepts to different pages even though the same name is sometimes used of them? That is, make one article about each of

• the programming language construct,
• the operating system signals,
• the hardware interrupts,
• the GUI events,
• the generalized condition systems.

They all have a different history and applications, even though some of the theory is common. If the theory warrants an article of its own, why not. --TuukkaH 10:15, 17 February 2006 (UTC)

History of?

Where did they come from? Was PL/I the first language to have full-blown exception handling, or just the first major one?--Prosfilaes 21:54, 3 June 2006 (UTC)

Vandalism?

Are these two blankings [6] [7] on 2006-06-17 (almost 2 weeks ago) by 220.227.211.221 (talk · contribs) vandalism or not? --Piet Delport 00:03, 30 June 2006 (UTC)

Merge with trap (computing)

I've proposed that we merge trap (computing) into this article. Traps are basically the same as exceptions, so having a seperate page seems redundant. If people agree, we should just have trap (computing) redirect to this page. Some extra information on this page about processor level exceptions would probably be good...maybe I'll get around to that. David.kaplan 03:38, 11 October 2006 (UTC)

But what about a trap to enter kernel mode: I don't think that classifies as an exception.--BMF81 06:16, 11 October 2006 (UTC)

I don't think this is the same thing at all, really. For one, you can return from a trap, but not from an exception. Also, they're really at different levels ... an exception is a construct in a programming language, whereas a trap is a hardware/kernel event. It would be like redirecting "conditional branch instruction" to "loop" or something. --FOo 07:49, 11 October 2006 (UTC)

Agreed. They have very little in common. --Piet Delport 15:07, 11 October 2006 (UTC)

That's completely not true. An exception can also be processor generated...page fault, divide by 0 exception, just to name a few. You return from page faults all the time (on demand paging). Perhaps part of the problem is this article incorrectly focuses completely on software exceptions and ignores hardware exceptions which have some similarities and differences. David.kaplan 01:35, 12 October 2006 (UTC)

Then why don't you deal with hardware exception handling in trap (computing). An exception in a high-level language isn't very similar to a processor exception.--Prosfilaes 12:19, 12 October 2006 (UTC)

Agree. Processor-level and programming-level exceptions, while having some similarities, are wildly different in practice and have very divergent behaviors. Separate the articles, but a cross-reference could be useful.

I think merging trap and exception is BAD idea. Trap is not just usual exception, it is very special exception and it is very important during study about operating systems. Placing trap inside exceptions will mislead readers. I think trap article should go in context of operating systems. For example, I didn't find reference to "trap" from "kernel mode" article, and I think it should be one. For exceptions article it will be enough to just add reference to trap.

• I don't support the merge either. Perhaps a name change to Exception (software)? —Doug Bell ^talk 19:52, 13 December 2006 (UTC)

Checked exceptions section

I tagged this with pov-section since it deals almost exclusively with Java. (Sorry if this is not the appropriate tag.) Many other languages probably have concepts similar to checked/unchecked-ness, so add them there if appropriate. 68.111.72.167 16:18, 15 October 2006 (UTC)

POV implies that the information that's presented isn't true, whereas this is more of a case of there being insufficient information. I don't think the reason why the section only deals with Java is that it's biased toward Java. I changed the template to "expand section". Magnus Bakken 17:42, 3 December 2006 (UTC)

Hi, I wrote more and added references to make it clearer why the section is not POV or insufficient: it just happens that checked exceptions were invented by the designers of Java, and for some reason designers of other languages see more cons than pros in supporting them. It's also hard to find information on which features should be considered "similar", but you can't say mentioning OCaml, CLU and now also Modula-3 is nothing! --TuukkaH 02:53, 7 December 2006 (UTC)

The statement that checked exceptions were "devised" by the Java developers is not true. The concept existed prior to Java and was in several earlier languages that used exceptions. (Unfortunately, my memory fails me as to the name of the real "guilty" party here.) 21:52, 7 July 2013 (UTC)

finally clause

What is the finally clause good for when it behaves as if it was not used alltogether, regardless of whether a exception has occured or not? --Abdull 09:32, 9 April 2007 (UTC)

Inner Exceptions

I came here hoping to have these explained to me. If someone in the know could add a mention of these and what they are for, then I'm sure it will be beneficial - Thanks! 196.212.4.66 13:55, 7 June 2007 (UTC)

handler/function

In general, current state will be saved in a predefined location and execution will switch to a predefined handler.

I think it would be a little more clearer if this sentence added ", specifically a function or subroutine."

What do you guys think. I didn't want to alter it since it was so close to the top.--Michael miceli (talk) 00:52, 13 March 2008 (UTC)

I don't think I agree with that statement. In any language I know, exception handlers are not a separate function, just another scope or similar construct. (Skimming at the exception handling syntax article doesn't demonstrate any clear contradiction to this.) Sometimes error reporting is done by calling a callback, but that's not an exception.

EvanED (talk) 01:56, 13 March 2008 (UTC)

Assertion "C++ does not need finally"

I find the assertion "Notably, C++ does not need and does not provide this construct [finally]" to be partly wrong. It is true that C++ does not provide a "finally" construct, but I for one would welcome it.

While it is true that the "Resource Acquisition Is Initialization technique" is common in C++, it is not ideal in all scenarios, and it is (on its own) not enough to justify the lack of the "finally" construct, which I think it's really a weakness in the C++ language.

As an example, I think Borland compilers offer a proprietory __finally clause for C++. 82.207.169.34 (talk) 11:02, 26 August 2008 (UTC)

Confusion between program language exceptions and hardware signals

Description seems to make programming language exceptions (throw Foo) same thing as hardware interrupts/signals/faults/traps. IMHO these are very different - one is relatively high-level purely software thing that depends on language and can be implemented in various ways (see Common Lisp), and another is very low-level hardware-dependent. —Preceding unsigned comment added by 82.28.217.36 (talk) 17:42, 16 May 2009 (UTC)

I only know hardware exceptions as interrupts. Perhaps it is an idea to dedicate the interrupt article to hardware interrupts, and this article to programming language constructs for dealing with exceptions, with see-also links at the top of both articles. Rp (talk) 09:17, 18 June 2012 (UTC)

Continuations

This article should cover the comp-sci aspects of exceptions, and specifically that they can be (easily) implemented on top of continuations. (they're basically just a simple special-case of continuations). linas (talk) 17:15, 23 August 2009 (UTC)

Error Handling is Not Exception Handling

As pointed out in this article, error handling is not exception handling, and deserves to have a separate article, containing the information in this article pertaining to "Error Checking."

The distinction is clear: Exceptions cause abnormal program flow whereas error handling is within normal program control, for example case else or WHEN OTHER constructs.

Error handling should not redirect to Exception handling.

Softtest123 (talk) 17:25, 16 November 2010 (UTC)

Exception handling can be used as an alternative to a 'goto' in C++. By throwing and catching integer values. Some programmers (not me) use this as a structured workaround to a 'goto' in situations where a 'goto' is not permitted. As such the throw/catch mechanism can be part of the normal program control. QuentinUK (talk) 00:49, 2 July 2011 (UTC)

ARM7

This EE Times article "How to use ARM's data-abort exception" may be of use here (possible issues of WP:NOTHOWTO and WP:UNDUE aside). I'm not a programmer, so can't really tell. -- Trevj (talk) 13:38, 7 March 2012 (UTC)

Exception specification redirect

Arriving at this page from the Exception_specification redirect there is floating "This is a tool icon" text with "[x]" text above it on the right hand side of the screen. This does not appear when navigating to this page directly. I would remove it, however I can not work out how to do so. 120.148.211.87 (talk) 18:20, 18 May 2012 (UTC)

Split into separate articles for HW & SW exception handling?

This article is fairly lengthy, and covers a wide range of exception-related topics. Could it be an idea to split it into one "Hardware exception handling" and "Software exception handling" article to narrow-down the scope a bit?Fredrik Orderud (talk) 15:04, 2 January 2013 (UTC)

I don't think that is a good idea. The hardware/IEEE 754 floating point stuff is only a small part of the whole article and it is an important aspect of exception handling in general- e.g. a programmer may use both C++/Java style exceptions and floating point flags/default presubstitution in the same code and needs to know about both (in particular many programmers have a poor understanding of floating point exception handling). I think the later more esoteric sections on implementation of exceptions etc could be broken off into a subarticle if necessary. 121.45.213.224 (talk) 05:46, 29 January 2013 (UTC)