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)

Common Lisp specifies 'restarts' which allow to resume after a condition (a generalization of exceptions) has been signaled (raised). The example seems like an excerpt from Peter Seibel's book "Practical Common Lisp", see http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html — Preceding unsigned comment added by 50.0.45.6 (talk) 22:12, 24 January 2015 (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)

History should mention some earlier works. In particular, Goodenough(1975) http://www.cs.colorado.edu/~bec/courses/csci5535-s09/reading/goodenough-exceptions.pdf was an influential (if flawed) paper that affected several later designs. drh (talk) 22:13, 7 July 2013 (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.) (Just remembered the name -- Goodenough -- kinda memorable.) drh (talk) 21:59, 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)

"An empirical study of goto in C code" (2015 paper) https://peerj.com/preprints/826v1.pdf and https://peerj.com/preprints/826v1/ quote "We conclude that developers limit themselves to using goto appropriately in most cases, thus suggesting that goto does not appear to be harmful in practice." • Sbmeirow • Talk • 21:56, 16 February 2015 (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)

Throwable vs Exception

Nigelj has reverted the mention of throws Throwable under Java checked exceptions to throws Exception with the explanation "Throwable may be more general, but they do not need to have anything to do with 'Exception handling' - the topic of this article, and paragraph". However, this does not make much sense.

It is very clear that Throwable is considered to be a checked exception. For example the documentation of Throwable says "For the purposes of compile-time checking of exceptions, Throwable and any subclass of Throwable that is not also a subclass of either RuntimeException or Error are regarded as checked exceptions.". In order to catch all checked exceptions, it is necessary to use Throwable, not Exception. Not only is this highly relevant to the topic of the page, but the current version is misleading and incorrect. Hiiiiiiiiiiiiiiiiiiiii (talk) 01:59, 16 April 2014 (UTC)

If the edit had stood, it would have contradicted the cited source at the end of the paragraph. The Java™ Tutorials > Essential Classes > Exceptions says that even catch (Exception e) is "A (too) general exception handler". It goes on: "In most situations, however, you want exception handlers to be as specific as possible. [...] Exception handlers that are too general can make code more error-prone by catching and handling exceptions that weren't anticipated by the programmer and for which the handler was not intended." Throwable is parent to all Exceptions, and to all Errors. The JavaDoc to Class Error says "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. [...] That is, Error and its subclasses are regarded as unchecked exceptions for the purposes of compile-time checking of exceptions." It is much better to write article text based carefully on what the reliable sources say, rather than on personal opinion. See WP:V. --Nigelj (talk) 11:19, 16 April 2014 (UTC)

That source does not contradict anything I said. The current wording of the article is incorrect, and that's a fact, not an opinion. Perhaps as a compromise, we could remove the word "minimal", and change "is sufficient" to "is usually sufficient". That would remove the factual errors without mentioning Throwable, which you seem to oppose. Hiiiiiiiiiiiiiiiiiiiii (talk) 22:18, 18 April 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Exception handling. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Attempted to fix sourcing for http://danweinreb.org/blog/what-conditions-exceptions-are-really-about

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 15:29, 28 August 2015 (UTC)

The archive link was not functioning in my browser. I corrected it to a functioning link that was grabbed 4 months earlier. I set the "checked" parameter to true above. --Jhertel (talk) 12:53, 29 August 2015 (UTC)

Hardware vs Programming language exception

There are many differences between an hardware exception, software error handling and especially a programming exception constructs. IMO, this text should be reshaped to make clear those differences. Conceptually, programming exception are just a control flow syntax, which could be replaced by others; While hardware exceptions or software error handling are strategies to manage exceptional situations.

Paragraph 2: No, programming exceptions do not save the state neither trigger subroutines, that is only hardware exceptions. Programming exception mostly pop the stack until a catch is found or the software is terminated. The example of "continuable" is a consequence of that: The divide-by-zero is a hardware exception, while out of memory is software error handling. Out of memory exception should be managed internally, and will only terminate the execution if the software did not.

In general, this text is making a mix between error-handling, hardware exceptions and programming exceptions. It need IMO a major rewriting to be correct.

Escain (talk) 12:23, 7 November 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 5 external links on Exception handling. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive http://wayback.vefsafn.is/wayback/20131110061200/http%3A//processors.wiki.ti.com/index.php/Main_Page to http://processors.wiki.ti.com/
• Added archive https://web.archive.org/web/20120101053153/http://software.intel.com/en-us/articles/how-to-implement-software-exception-handling/ to http://software.intel.com/en-us/articles/how-to-implement-software-exception-handling/
• Added {{dead link}} tag to http://archives.java.sun.com/cgi-bin/wa?A2=ind9901&L=rmi-users&F=P&P=36083
• Added archive https://web.archive.org/web/20080418123816/http://www.chrisjhill.co.uk/Articles/PHP_exception_handling to http://www.chrisjhill.co.uk/Articles/PHP_exception_handling
• Added archive https://web.archive.org/web/20051125071334/http://www.gamedev.net/reference/programming/features/sehbasics/ to http://www.gamedev.net/reference/programming/features/sehbasics/
• Added archive https://web.archive.org/web/20100418004122/http://www.amcgowan.ca/blog/computer-science/how-to-handle-class-constructors-that-fail/ to http://www.amcgowan.ca/blog/computer-science/how-to-handle-class-constructors-that-fail/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:38, 27 July 2017 (UTC)

I submit attached receipt of my medical lens/frame being purchase from the Eyecare for African on 16th August, 2017 for your kind approval for payment.

I submit attached receipt of my medical lens/frame being purchase from the Eyecare for African on 16th August, 2017 for your kind approval for payment.