Talk:Exception handling

From Wikipedia, the free encyclopedia

Contents

[edit] 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).

[edit] 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?

[edit] (Un)Checked Exceptions

Very nice guys! Perhaps we should include a bit about checked and uncehecked 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)

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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)