Poll #12

  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Show All Polls | Show Comments | Submit Comment ]

Poll #12

Should FLTK 2.0 use C++ exceptions for error handling?
Yes, use exceptions all the time. 500 / 33%
Yes by default, but make it a compile-time option. 455 / 30%
No by default, but make it a compile-time option. 233 / 15%
No, don't use exceptions at all. 197 / 13%
I couldn't care less. 94 / 6%
1479 total votes.

User Comments

Submit Comment ]

From Anonymous, 04:22 Jan 09, 2003 (score=4)

Actually, when used, exceptions should be derived from an own type let's say fltk_exception or so to allow the usage of a singe catch-statement.
Reply ]

From Anonymous, 08:52 Jan 10, 2003 (score=4)

And fltk_exception in turn should derive from std::exception, to make the last-but-one resort
   catch(std::exception& ex) {
      std::cout << "An exception happened for which I dunno"
                << " how to react to" << ex.what() << std::endl;
   } in main- or any other suitable function - to work.

Just for the records: The last resort is
   catch(...){
     std:.cout << "Something bad happened, dunno what." << std::endl;
   }

BTW, before starting to use exceptions, make sure to understand all issues discussed e.g. by Sutter or in the boost exception rationale.
Reply ]

From Anonymous, 01:32 Jul 21, 2003 (score=3)

Hey, this is C++ after all, so use it!
Reply ]

From MichaelRynn, 07:47 Jan 18, 2003 (score=3)

Error handling is a part of any non-trivial program, and exceptions are inherent in many libraries eg STL. Still others manage to avoid them, returning error codes when something goes wrong, eg ACE Lib. Exceptions are hard to work well from some DLLs in windows.  Therefore, Exceptions should be left up to the implementation. There is probably a point in complicated software where it becomes easier to make it throw an exception for an extraordinary condition, than to return and check error codes down a long call chain. I don't know the insides of FLTK enough to comment, but most general purpose libraries which do a lot of OS interaction also provide exception handling. When well done, it seems to make life easier. Is there a way of designing so that the number of Exception classes is minimal but gives the maximum amount of exception information?  The problem is once an exception base class exists, everyone seems to make another special derived one just for their unique class purposes.  If the number of additional exception classes can be limited, because it doesn't really need expansion, it might be more tolerable.
Reply ]

From Alexey Parshin, 19:36 Jan 16, 2003 (score=3)

Mike,

A lot of comments are coming from anonymous. May be you just detect it in JavaScript and ask to provide a real name, at least?
Reply ]

From Mike Sweet, 22:23 Jan 16, 2003 (score=1)

I've been thinking of adding a check box (post as anonymous coward) and require a name otherwise...  We'll see...
Reply ]

From Helge Blischke, 13:59 Jan 15, 2003 (score=3)

I think the overhead due to exception handling is comparable to the oberhead of return code handling or even less. And the code gets much more readable and maintainable when using exception handling.
Reply ]

From Mike Sweet, 14:10 Jan 15, 2003 (score=3)

The overhead of an exception is roughly equivalent to a setjmp in C, which is at least an order of magnitude slower than comparing the return value of a function.

Like most things in life, exceptions are best used in moderation. I like the previous poster's idea of throwing the exception from a callback, so that a variety of error handling mechanisms can be used.
Reply ]

From Alexey Parshin, 19:39 Jan 16, 2003 (score=2)

I've tried to measure the speed the exceptions. Well, on my machine it's about 800..900 exceptions per second :) Considering, that I've 20..30 exceptions in one program per day - it doesn't sound too bad
Reply ]

From Ken Yarnall, 19:05 Jan 16, 2003 (score=1)

The important aspect of exception efficiency is that they should impose no cost when they aren't thrown.  I know that GCC is now very close to that goal (I think that there is an instruction or two burned for the sake of exception handling, but that's it).  I presume that other compilers are, too. 

BTW, the GCC exception mechanism is now a table-driven approach; they dumped the setjmp/longjmp technique awhile ago.  I belive this is a performance win, but I don't really know.

If you use exceptions as a control-flow mechanism, you're just being silly.  If you use them consistently as a remote error reporting mechanism, then they provide a nice alternative and can really help clean up code.

Ken
Reply ]

From Dejan Lekic, 17:26 Jan 18, 2003 (score=1)

I _DON'T_ think code is much more readable with exceptions, especially when You try to catch a lot of things. IMHO, exceptions do otherwise - they make code UNREADABLE. And when I consider writing cross-platform libraries ... As I said long time ago - FLTK should have exceptions, maybe even it should be turned ON by default - but I would like to see the configure option to get rid of them. 95% of developers (now) don't care about resources so much there will be allways enough memory, harddisk space and so they use exceptions and STL all the time. I am in those other 5% sorry.
Reply ]

From Anonymous, 04:18 Jan 14, 2005 (score=2)

I have not used exceptions much in C++, but in Java the one problem is that if the exception is not caught then it "floats to the top" and the JVM shuts down the program.

The problem with error checking in c is that you don't have to do it.  So you could end up with an error that might manifest itself in a weird way.

For programs that users see I typically program to catch as much as possible if not all.  Programs to do something I need done, I usually program pretty fast and loose.

I think as library you should lean to the most stability and robustness, and just make us type more.
Reply ]

From Anonymous, 18:52 Sep 25, 2004 (score=2)

I think fltk should use it's own error handling due to the difference from implementation to implementation.
Reply ]

From Anonymous, 09:13 Jan 14, 2003 (score=2)

Not using exceptions would just simply be wrong and sick, it's C++ not C, so one should use those error-handling mechanisms.

Making exceptions optional is IMHO a mistake, because you'd never know how to handle errors in fltk applications: it depends on how the FLTK library has been built. So you'll end up handling both exceptions and return codes (!!!), which is unacceptable.

Has anyone a good point on why exceptions shouldn't be used ?

FLTK is in C++, so do C++ and don't cripple it down to some C with //-comments, please ;-)
Reply ]

From Mike Sweet, 09:43 Jan 14, 2003 (score=3)

1. Exceptions are not always supported

2. Exceptions add a substantial amount of overhead when used with many popular compilers (GCC, for example).

3. Because of #1 and #2, we will likely limit their use in FLTK to "fatal" areas such as memory allocation, display setup, etc. That will allow non-fatal error handling to continue no matter what compiler/build options you use.


Reply ]

From Dejan Lekic, 06:03 Jan 16, 2003 (score=3)

Exactly Mike, exceptions are C++, and should be in FLTK, but it must be optional... Simply sometimes I just don't need exceptions in my application(s).
Reply ]

From Anonymous, 20:45 Jan 21, 2003 (score=1)

Modern compilers, Intel C++ 6.x+, Visual C++, GCC 3.x+ use a zero-overhead exception mechanism. So the only hit is a size overhead for the exception tables, but that size overhead only matters when an exception is actually thrown and that code has to be paged in.
Reply ]

From Alexey Parshin, 19:33 Jan 16, 2003 (score=1)

Exceptions are supported with most of the modern compilers. Even VC++ compiling WinCE apps is included. To compile EFLTK with something so old that doesn't have'em? Well, it's not a reason to keep the whole project down to stone age. The overhead of exceptions is huge, enormous, impossible - 5%..7% of program size and no difference in speed, isn't it too much? :) Now, consider that you are trying to develop something robust, prepared to tough environment. You must handle errors of every file-, memory-, database-, input data-related operations. Guess what will be the size increase of the custom and nice error-reporting system? Exceptions, from other hand, provide simple, with minimal overhead, way to report any error through any deep function sequence. You can catch them where it's convenient for you. Moreover, exceptions make your to build your program to catch them :) and be prepared for errors, which is a good way to build a stable program.
Reply ]

From Mike Sweet, 22:21 Jan 16, 2003 (score=2)

It is important to remember that exceptions add overhead to the entire program; for example, FLUID (in 1.1.x) increases from 678024 to 854056 bytes, an increase of 176032 bytes or almost 26%, not 5-7%.

Also, there are a lot of (older) C++ compilers that have missing or faulty exception support that are otherwise excellent.

In short, given the results of the poll so far, we are inclined to add optional exception support using an indirect method that will also allow for convenient non-exception based error handling.  Even if FLTK itself is compiled without exception support, the error handling function can still throw exceptions from a user program...
Reply ]

From Ken Yarnall, 09:46 Jan 18, 2003 (score=1)

I'm not sure that's true.  If the library is compiled without exception handling turned on (on gcc, anyway), then if I understand correctly the stack frame will not be set up correctly.  If your callback throws, and there are functions on the stack that aren't compiled with exceptions enabled, then I believe that Bad Things may happen.  After all, if an exception is thrown, then every function the exception passes through has work to do (calling destructors, etc).

Ken
Reply ]

From Mike Sweet, 18:51 Jan 20, 2003 (score=1)

That's true; the error callback would only be able to send exceptions if you have compiled FLTK with exception support (which means we'll probably need to at least have a header file and/or fltk-config interface that tells the app whether FLTK was compiled with exception support.
Reply ]

From jaroslav.fojtik, 09:07 Dec 29, 2004 (score=1)

Hi, I have very wrong experiences with exceptions (in C#). They could cause a BIG headache when normal property like position returns an exception. In this language everything could return an exception so every procedure must start with "try {}" Every exception could occlude your code.
   It is a good idea to use exceptions, but for something very rare. Not  as a replacement of standard return codes.
Reply ]

From shkolyar, 08:05 May 05, 2005 (score=3)

Hey. Can you (or somebody else) please explain how to configure the VS.NET C# project to work with fltk? Thank you in advance, Slava.
Reply ]

From Hans Yperman, 11:50 Jan 15, 2003 (score=1)

Why not try this: If you want to write
   throw some_fltk_exception; make it
   Fl::handle_error(some_fltk_exception);
   return;

Fl::handle_error then calls a function defined by the user.  This function might be defined to throw an exception.  It might implement another way of error handling.  This way, the program can decide if it wants exceptions.

One closing remark: the default handle_error function should not throw anything, as this will break backward compatibility.  Programs that want exceptions should do something like Fl::set_error_handler(Fl::throw_exception_on_error);
Reply ]

From Anonymous, 16:22 Jan 17, 2003 (score=5)

Allright, but this still does not solve your problem with faulty exceptions implementation (i know at least one GCC - i think 2.95.something that is still widely used (it comes with redhat 6.something) that generates faulty code). After reading the posts here, i think two main conclusions can be drawn:

1. There must be a mechanism to disable exceptions *at preprocessing time* so that compilers ith problems won't even see them.

2. Given 1. , the exceptions must be used extensively (not only for critical errrors. People who use exceptions (including myself :-) like to use them consistently - not only for the "more critical" parts. I think the best way is to come up with a consistent exception hierarchy that covers all the common types of "exceptional cases". Then just ask people to use them - people tend to use existing frameworks/common practice.
Reply ]

From Hans Yperman, 12:33 Jan 22, 2003 (score=5)

I don't agree with this:

1. The faulty compiler only gives you trouble when an exception is thrown. When no exceptions are used, nothing will go wrong.  Besides, with my solution, nothing has to change in the headers (=preprocessing time), as C++ assumes that a function without a throw-clause can throw almost anything.  The only changes needed, (set_error_handler declaration and exception class definitions) could live in their own header.

2. To me,this point seems not to be an issue.  Define all the needed exception classes, and call handle_error consistently (not only for critical errors). When the library user chooses throw_exception_on_error as the handle, [s]he has what you propose.  And yes, the argument to handle_error should be the base class of an exception class hierarchy.  But the program should not be forced to use exceptions if it does not want. 

My opinion: My test program seems to say there are no big technical reasons not to compile with -fexceptions by default. The comments here demonstrate that not all of us want to use exceptions.  Also, just starting to use exceptions breaks backward compatibility.  So why not give the choice to the writer of the program ?
Reply ]

From Anonymous, 13:25 Jan 03, 2003 (score=1)

I think the first two options (all the time vs compile-time switch) can be safely merged into the second. This will make everyone happy (those who want exceptions all the time will get them by default, but those who don't (and this can be more than just a matter of taste, some C++ compilers still have problems with exceptions) can still de-activate them).
Reply ]

From Michael Sweet, 13:37 Jan 03, 2003 (score=1)

I'm not sure what will happen if you mix code that was compiled with exception support with code that was not; it is possible that the exceptions will get silently ignored, or it could blow up, or fail at link time.

It's easy enough to add a configure-time option, and then the corresponding compiler option(s) can be included if needed (since C++ name mangling is not portable between compilers, this shouldn't pose a problem)
Reply ]

From Anonymous, 13:59 Jan 03, 2003 (score=2)

The problem with a configure-time switch is that once you installed fltk with exceptions, you cannot safely compile code that was written without exceptions in mind (an of course the other way around). How about

#ifndef FLTK_DONT_USE_EXCEPTIONS # define FLTK_THROW #else # define FLTK_THROW blah blah #endif

inside fltk code, then compile with -DFLTK_DONT_USE_EXCEPTIONS to disable them. And of course you need to install two versions of the libraries, one with and one without exceptions. Ugh, this becomes complicated......
Reply ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2015 by Bill Spitzak and others. This project is hosted by Seriss Corporation. Please report site problems to 'erco@seriss.com'.