Talk:Exception handling

Lexically Scoped Exceptions?!

"PL/I used dynamically scoped exceptions, however more recent languages use lexically scoped exceptions."

This is so bad it's not even wrong. By *definition* an exception is dynamically scoped. Lexical "exceptions" would offer no more that Common-Lisp's "block/return-from", or a "break" and "continue" that were allowed to escape from functions lexically inferior to the containing loop. in C or JavaScript etc.

To make matters worse, we then go off and talk about "Languages where exceptions are only used to handle abnormal, unpredictable, erroneous situations: C++,[8] C#, Common Lisp, Eiffel, and Modula-2.".

This is completely wrong. For example, `throw` and `catch` in common lisp are *not* used for abnormal situations. They are almost exclusively used to bail early through nested calls to return a result early, rather than error handling. The article even goes that far by explaining how Lisp 1.5's errset and err were re-designed as `throw` and `catch` to allow this behaviour *AS A CONTROL CONSTRUCT* in MacLisp. Common lisp does not use throw/catch for exception handling, since it has a totally separate condition system that doesn't force one to unwind the stack, and using throw/catch completely removes you from an entire, significant area of the language designed to deal with exceptions.

Overall this page is far to long, totally contradictory and generally inaccurate. It is in urgent need of review by a specialist.

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).

This is completely incorrect, please stop talking. Exceptions (including finally blocks) can be entirely implemented (modulo syntactic support) in C and hence objective C using setjmp/longjmp, and trampolines are a user-space calling convention. Wikipedia is not a platform for you to just publish the true majesety of your uninformed reckons, that is what Facebook is for. this page covers a topic that is extremely well understood and has been thoroughly analysed over the last 50 years in the PLT research community- entire academic careers have been built on the topic. Yet this page is intellectually mutilated to the point of deception with numerous factual inaccuracies. I am not entirely sure even that the concept 'Exception' and 'Exception Handling' should have been merged, since now we just have an enormous monolith that tries to explain MMU exceptions and conflates them with structured exception handling and escape continuation, while dramatically not explaining any of them. If none of you can be bothered to consult the literature, you should not be involved in this page. This article does not even pass a first year quiz on the topic. It URGENTLY requires specialist review.

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)

An edit on February 19, 2006 by TuukkaH had changed a parenthetical definition of unchecked exceptions from "RuntimeExceptions and Errors" to "RuntimeExceptions and non-Exception Throwables". I don't believe this revision is correct (it doesn't agree with the JLS), but wanted to open a dialog here to confirm consensus on reverting. This revision would, for example, imply that a class Foo that directly extends Throwable is unchecked, which isn't the case. --Mike Fikes 14:33, 25 February 2006 (UTC)

Thanks for noticing my thinko, I've now reverted it. --TuukkaH 23:55, 25 February 2006 (UTC)

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)

My understanding of checked exceptions is they are very much the exception (excuse the pun) than the rule. The Java language added them thinking it would help, but it turned out in practice to be a terrible idea that was heavily abused by practitioners (e.g. catching everything and discarding it, declaring everything as throws Throwable, etc). It appears an experiment that was added to the OAK language (as it was named before Java), but is generally regarded by language designers to now have been a poor decision. In particular C#, Java's closest relative in terms of era/platform approach, never adopted checked exceptions. — Preceding unsigned comment added by 86.138.131.253 (talk) 19:57, 15 February 2020 (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)

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)

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)

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)

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: 18 January 2022).

• 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)

Checked exception discussion...

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)

Split article to "Exception" and "Exception handling" ?

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)

"Exception(computing)" listed at Redirects for discussion

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)

== In software ==: is Golang in the first group?

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 , but am still hesitant to edit the section. Would someone more versed in Go do so? Jerzy 06:42, 15 July 2020 (UTC)

References

Effective Java: Use Exceptions only for exceptional conditions

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)

I went ahead and updated the main page by moving Java to languages that only use exceptions in exceptional situations.

Effective Java is considered a very reliable source in Java circles. Joshua Bloch designed the Java collections framework, which includes some of the most used classes and interfaces in the entire language (`List`, `ArrayList`, `Map`, `HashMap`) Techcable (talk) 18:35, 18 April 2021 (UTC)

Saving a spacecraft?

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)

Why the split?

@Fgnievinski I do not understand the logic behind your split. You have made two articles, this one on exception handling in computers and computer programming... and the other on exception handling in computer programing. This means there is no distinction in topic. I guess you meant to say that the second article was specifically on programming language mechanisms? But there is such a variation that it is more reasonable to discuss language mechanisms along with IEEE-754 and the other mechanisms. Furthermore per WP:SIZERULE length alone did not justify a split, the article was only 33kb before which is around the target article size. Even the flow of the article does not make sense anymore, for example the history section discusses programming language mechanisms and now those mechanisms are missing. Mathnerd314159 (talk) 15:04, 22 July 2023 (UTC)

The relevant policies are:

1. WP:N: "On Wikipedia, notability is a test used by editors to decide whether a given topic warrants its own article."
2. WP:GNG: "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject."
3. WP:PAGEDECIDE: "Does other information provide needed context? (...) Do related topics provide needed context? (...) What sourcing is available now? (...)"
4. WP:SPINOFF: "There are two situations where spinoff articles frequently become necessary: Articles where the expanding volume of an individual section creates an undue weight problem ..."

The narrower concept Exception handling (programming) passes all requirements above for notability. Furthermore, the broader concept Exception handling provides little context for understanding the programming concept. For example, "IEEE-754" is not even mentioned in the programming article, "hardware exceptions" is a very distinct concept, so is the UI concept. The broader article used to be disproportional, being 90% about the narrow concept. All other major sections already had their own main pages. fgnievinski (talk) 19:05, 22 July 2023 (UTC)