Talk:Exception handling

message: 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)
replies: text: 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)

text: 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)
thread_title: Continuable Exceptions?

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

message: 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)
thread_title:  Exceptions and signals 

message: "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)
thread_title:  Pros and cons 

message: 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)
replies: text: See above on why checked exceptions are a fairly rare feature in programming languages.  — Preceding unsigned comment added by 86.138.131.253 (talk) 19:59, 15 February 2020 (UTC)
thread_title:  Rules of thumb: Exceptions in Java 

message: 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)
thread_title:  Reorganization of articles 

message: 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)
thread_title:  History of? 

message: Are these two blankings   on 2006-06-17 (almost 2 weeks ago) by  vandalism or not?  --Piet Delport 00:03, 30 June 2006 (UTC)
thread_title:  Vandalism? 

message: 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)
replies: text: 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)
replies: text:  Agreed.  They have very little in common.  --Piet Delport 15:07, 11 October 2006 (UTC)

text: 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)
replies: text:  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)
thread_title:  Merge with trap (computing) 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Checked exceptions section 

message: 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)
replies: text: The purpose is to ensure that whether your code is aborted through an abnormal condition, or normally, it will ALWAYS execute the finally handler. For example, we may have some code that turns on a pump (or opens a database connection), but if suddenly something goes wrong, we must ALWAYS ensure, that no matter what, we turn off the pump (or close the database connection). a try ... finally block which does NOT handle an exception, says "I don't know WHAT to do with any particular exception, but if we screw up DEFINITELY do this"  — Preceding unsigned comment added by 86.138.131.253 (talk) 17:36, 15 February 2020 (UTC)
thread_title:  <code>finally</code> clause 

message: 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)
thread_title:  Inner Exceptions 

message: 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)
thread_title:  Assertion "C++ does not need finally" 

message: 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)
replies: text: 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)
thread_title:  Confusion between program language exceptions and hardware signals 

message: 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)
thread_title:  Continuations 

message: 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)
replies: text: 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)
replies: text: "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)
thread_title:  Error Handling is Not Exception Handling 

message: 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)
thread_title:  ARM7 

message: 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)
thread_title:  Exception specification redirect 

message: 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)
replies: text: 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)
thread_title:  Split into separate articles for HW & SW exception handling? 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Throwable vs Exception 

message: Hello fellow Wikipedians,
I have just added archive links to  on Exception handling. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  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.
Cheers. —cyberbot IITalk to my owner:Online 15:29, 28 August 2015 (UTC)
replies: text: 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)
thread_title:  External links modified 

message: 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)
thread_title:  Hardware vs Programming language exception 

message: 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  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.
Cheers.—InternetArchiveBot (Report bug) 03:38, 27 July 2017 (UTC)
thread_title:  External links modified 

message: The quote in the checked exception section is an excerpt that went through Eckels and Kiniry before it made it to the page here.
It would be better to link to the original full post, which can be found in the archive here:
http://web.archive.org/web/20060106013458/http://discuss.develop.com:80/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820
Thanks
Eric Gunnerson  — Preceding unsigned comment added by 2001:4898:80E8:7:0:0:0:7AE (talk) 17:27, 22 August 2017 (UTC)
thread_title:  Checked exception discussion... 

message: I'm just wondering if it would make more sense to make a page for "Exception" by itself in addition to this page? to me it seems like "Exception handling" is a verb and there isn't an article directly discussing the object called "Exception". I just finished making some edits to link the "trap (computing) page to this and back since the two terms are synonymous. When i went to edit the article for Trap itself i was going to link the text "Exception" to the article for Exception and then i realized that I just made these links and "Exception" by itself doesn't exist. I don't know i'm not a Encyclopedia/Wikipedia expert. Thoughts?  — Preceding unsigned comment added by Anthonybakermpls (talk • contribs) 16:58, 4 December 2018 (UTC)
thread_title:  Split article to "Exception" and "Exception handling" ? 

message: A discussion is taking place to address the redirect :Exception(computing). The discussion will occur at Wikipedia:Redirects for discussion/Log/2020 June 5#Exception(computing) until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  Tea2min (talk) 09:37, 5 June 2020 (UTC)
thread_title:  "Exception(computing)" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: Methinks Go should be included in the first group, along with languages where exceptions are designed to be used as flow control structures. I'm not sure though. I browsed through a blog article about it https://blog.golang.org/defer-panic-and-recover, but am still hesitant to edit the section. Would someone more versed in Go do so?
Jerzy 06:42, 15 July 2020 (UTC)
thread_title:  == In software ==: is Golang in the first group? 

message: This is Item #68 in the award winning and popular book by Joshua Bloch
I don't know why the article asserted otherwise......
Speaking as a Java programmer, I would have to agree with the book that it's generally considered extremely bad practice to use exceptions for control flow. Techcable (talk) 18:08, 18 April 2021 (UTC)
thread_title:  Effective Java: Use Exceptions only for exceptional conditions 

message: I know William Kahan invented IEEE 754 but his claim that IEEE 754 exception handling would save a spacecraft seems a bit WP:FRINGE. Full quote here (slide 22):
:Had overflow merely obeyed the IEEE 754 default policy, the recalibration software would have raised a flag and delivered an invalid result both to be ignored by the motor guidance programs,  and the  Ariane 5  would have pursued its intended trajectory
This seems a bit trite, for one because the types involved were not all floating-point. Does anyone else think this claim seems too strong to include in an encyclopedia? --Mathnerd314159 (talk) 22:22, 19 December 2021 (UTC)
thread_title:  Saving a spacecraft?