Most every programming language has exceptions, but I dont understand the need for them over regular error checking code. I took a Java course and we just used regular if statements to check input values from IO and it worked perfectly fine. Ive heard exceptions are not allowed in highly critical code as it makes unpredictable runtime logic. Can someone tell me what exceptions offer beyond error checking code that you could write on your own?
Also, exceptions are kind of inferior to conditions which allow restarting or continuations. Sadly Java and other "modern languages" have yet to get a real condition system.
Oh, from the title I thought this would be a bragging kopipe. I am disappointed.
Anyway NO EXCEPTIONS
Name:
Anonymous2010-05-06 19:01
>>3
Oh fuck, I feel stupid. I was myself thinking that a proper exception system would allow for actually handling exceptional conditions and continuing execution, rather than just "reporting" an exception to the nearest handler and aborting. Now thanks to your post I realized that you really only need a call/cc. In my defense, I haven't really programmed in a Lisp yet.
ALso, exceptions are a bit more than just error handling the way you do it in the C way.
Things like dereferencing a bad pointer, dividing by zero, executing an invalid CPU instruction, calling an interrupt, having an interrupt get signaled on an instruction, FPU exceptions, single-step breaks, hardware breakpoints, etc are all low-level exceptions which are usually supported by the CPU(architecture-dependent). Without them, you wouldn't be able to even have a damn error handler. These exceptions are a bit different from user exceptions as you've learned about in Java. They're low-level architecture details, and they're very important for both making more reliable and more stable systems, and they also prove to be very useful in debugging errors, and even building entire debug systems using them (on x86, you can set a trace flag and have an int1 get signaled on each instruction. If you play with some MSR regs, you can have it signaled on every branch. Int3 is used for breakpoints due to its small (intentional) 1 byte size. I could go on about them, but there's really no reason, when you could just pick up some CPU manuals and read about all this juicy stuff there.
Exceptions in languages like C and C++ (with OS-specific exceptions) are usually thin layers built on top of low-level exceptions provided by the OS, which are themselves almost directly built on the interrupt/traps subsystem provided by the CPU.
Exceptions in languages like Java, O'Caml, Common Lisp, etc are LANGUAGE CONSTRUCTS, which may or may not be built on top of C-like OS-specific exceptions or just low-level exceptions. If I remember correctly, O'Caml exceptions were built in a portable manner which didn't tie them to any CPU arch. This is actually a rather good choice as low-level exceptions usually mean switching to ring0 on x86 (due to the trap), and that may cause a context switch, which can be costly. A similar cost analogy can be made as the one between green threads/fibers and real threads. As for Common Lisp, I think it depends on implementation, but in the 2 implementations whose condition system's implementation that I've looked at had them based on low-level exceptions (with some exceptions to this rule, no pun intended - such as using page faults for GC purposes and automatic heap growing). A condition system is a bit fancier than an exception system as it allows you to restart a computation without unwinding the stack if you wish to do so (the user could for example, unwind the stack up until a high-level exception handler, then the user could choose to restart the computation where it was left for without having unwinded the stack - something which is NOT present in Java or C++'s inferior exception model. This is actually problematic as the logic for handling an exception might be better written locally, but the actual decision needs to be made higher up in the stack), while still allowing more classical constructs like UNWIND-PROTECT(think of Java's try{}finally{...}).
>>6 call/cc is indeed the most general (and theorethically elegant) solution to exception handling, but maybe it's a bit too general and costly for general-purpose exception handling. It also does not play too well with UNWIND-PROTECT-like constructs, without crippling one construct or the other.
Name:
Anonymous2010-05-06 23:42
>>8
yeah, goto is the most general solution. but there's a reason it's considered harmful.
>>9
goto is fucking awesome. so many times I've seen code that could be greatly simplified with just a little goto action; instead it relies on redundant (or nonexistent) error handling and cleanup, additional status variables for loop conditions, etc.
>>10 goto is fucking awesome.citation needed so many times I've seen code that could be greatly simplified with just a little goto actioncitation needed; instead it relies on redundant (or nonexistent) error handling and cleanup, additional status variables for loop conditions, etc.citation needed
Name:
Anonymous2010-05-07 5:45
exceptions vs goto is like American bureaucracy vs Nigerian bureaucracy. You get what you paid for.