Board index » delphi » Exceptions in BCC 4.5

Exceptions in BCC 4.5

How do I use exceptions in BCC 4.5?
The following code does not end in the catch-branch, but results in a GPF.

        try{
                char *p = NULL;
                strcpy(p,"Good luck");
        } catch (...) {
                ::MessageBox(0,"something terrible happened",0,0);
        }

Under Project options -> C++ Options -> Exception handling all switches are turned on.

Thanx, Bruno.

 

Re:Exceptions in BCC 4.5


Quote
"Bruno Skorepa" <Br...@Skorepa.com> writes:
> How do I use exceptions in BCC 4.5?
> The following code does not end in the catch-branch, but results in a GPF.

>    try{
>            char *p = NULL;
>            strcpy(p,"Good luck");

This dereferences a null pointers. The result is undefined behavior, but
in practice you'll get a program crash, as you have experienced.

Why would you expect an exception to be thrown in this case?

Re:Exceptions in BCC 4.5


Quote
>>        try{
>>                char *p = NULL;
>>                strcpy(p,"Good luck");

>>This dereferences a null pointers.

Of course.
I know that.
But Visual C handles that case as an exception,
and some other weird errors as well, which comes
in handy.

What I am used to is:

   try {
       some_normal_coding;
   } catch (myFirstexception e1) {
       handle_1st_exc;
   }  ....
   }  catch (myLastexception en) {
       handle_last_exc;
   }  catch(...) {
      // in Visual C this handles all the rest
      // which means that the program NEVER crashes
      // even in the worst cases
   }

Thanx, Bruno

Re:Exceptions in BCC 4.5


Quote
"Bruno Skorepa" <Br...@Skorepa.com> writes:
> But Visual C handles that case as an exception,
> and some other weird errors as well, which comes
> in handy.

Aha.

I have always considered this to be a very bad idea. Dereferencing a
null pointer is a programming error. The exception mechanism was designed
to allow unexpected or infrquent behavior (typically outside the control
of the program) to be handled conveniently.

Quote
>    try {
>        some_normal_coding;
>    } catch (myFirstexception e1) {
>        handle_1st_exc;
>    }  ....
>    }  catch (myLastexception en) {
>        handle_last_exc;
>    }  catch(...) {
>       // in Visual C this handles all the rest
>       // which means that the program NEVER crashes
>       // even in the worst cases
>    }

Maybe that's just me, but I prefer a crash when I have goofed up.

Re:Exceptions in BCC 4.5


Quote
>>Maybe that's just me, but I prefer a crash when I have goofed up.<<

As long as you are developing, of course.
Once the program is being used by a "real" user, definitely not.

Only one of many examples:
About 3-4 years ago I worked for a Speech Recognition company and
wrote a little tool that used several DLLs that I did not
have any source of. (well I could have had, but that's not the point)

The main function I had to call crashed once in while,
maybe one out of 1000 times.
So I put a try-catch-block around, and when it crashed, the user
did not even notice, because I cleaned up and called the function again.

The program was sold to end-users.
Do you really think, that 1000s of end-users would have preferred to
see a GPF?
I guess not.

Quote
>>Dereferencing a null pointer is a programming error. <<

The coding I posted was meant to be short and BAD, and make the program crash.
I do not program that way, it is a sample.

Thanx, Bruno.

Re:Exceptions in BCC 4.5


Quote
"Bruno Skorepa" <br...@skorepa.com> writes:
> The program was sold to end-users.
> Do you really think, that 1000s of end-users would have preferred to
> see a GPF?

No. They'd prefer you to fix the bug.

Re:Exceptions in BCC 4.5


Quote
>> No. They'd prefer you to fix the bug.<<

This is going far away from my original question.
Maybe we should start another thread about bug-philosophy.

But seriously:
When I read my first programming book about UCSD-Pascal
(that was even before TP) there was a chapter about bug-fixing,
and I said to myself : "There will be no bugs in my programs".

It did not take too long and I had to realize that indeed there were bugs in
my first programs, and I had a hard time to fix them.
But I still thought that was just due to the fact that I was still a
beginner.

20 years later I do not consider myself a beginner anymore and I have
strategies to avoid bugs.
If you are on your own, write a program from scratch and have as much time
as you want, you will be able to end up with a program that has no
apparent bugs.

But in a real life situation it is not as easy as that.
First of all you are ususally not on your own, but depend on other
people's code  (and other people depend on you).
Then there are release dates you have to meet.
When those nice boxes are ready to be shipped, the CD-burners are waiting,
it is Friday evening and you and 5 others have spent a week to track down
one {*word*193} bug, you are quite happy to find a quick solution.

For me real life right now looks like this:
The company that I am working for had bought an application
without really looking into it (only sales-people had decided).
It did not take too long and they realized that the program was  quite
buggy, and old-fashioned (still a Win3.1 program).
So they hired me as a consultant to see what could be done.
I would say: "throw it away and start again from scratch".
But that is not an option for several reasons (takes too long, too
expensive, 600 users waiting for an update,
the people who had bought the program would be fired,....)

Working programs have on average 3 bugs / 1000 loc.
This is a buggy program, so assume 6 bugs/1000 loc.
I have 200.000 loc, makes an estimate of 1200 bugs.

In a real life situations you sometimes need a quick solution
and trapping Systemexceptions in the catch-branch is such a solution.

Thanx,  Bruno.

PS: I am still interested in an answer to my original question.

Re:Exceptions in BCC 4.5


Hello,

I think that the
try {} catch () {}
construct can only catch C++ exceptions, which are raised by the keyword throw.

If you want to catch exceptions like dereferencing a NULL pointer, you must use the construct
try {} __except() {}

I don't know if it is supported under Borland C++ 4.5, but 5.02 has it.

Here is the example from Borland C++ 5.02 Help File:

// try example
// In PROG.C
void func(void) {
   // generate an exception
   RaiseException( // specify your arguments );

Quote
}

// In CALLER.CPP
// How to test for C++ or C-based exceptions.
#include <excpt.h>
#include <iostream.h>

int main(void) {
   try
   {            // test for C++ exceptions
      try
      {         // test for C-based structured exceptions
         func();
      }
      __except( /* filter-expression */ )
      {
      cout << "A structured exception was generated.";

      /* specify actions to take for this structured exception */
      return -1;
      }
      return 0;
   }
   catch ( ... )
   {
   // handler for any C++ exception
   cout << "A C++ exception was thrown.";
   return 1;
   }

Quote
}

----
Jogy
http://www.jogy.net/
j...@sirma.bg
Quote
"Bruno Skorepa" <Br...@Skorepa.com> wrote in message news:3ccfa8b3$1_1@dnews...

> How do I use exceptions in BCC 4.5?
> The following code does not end in the catch-branch, but results in a GPF.

> try{
> char *p = NULL;
> strcpy(p,"Good luck");
> } catch (...) {
> ::MessageBox(0,"something terrible happened",0,0);
> }

> Under Project options -> C++ Options -> Exception handling all switches are turned on.

> Thanx, Bruno.

Re:Exceptions in BCC 4.5


my understanding is that C++ acceptions
are triggered by using throw.
__except would catch "structured acceptions"
im not sure about bcc 4.5 or VC,
i use BCC55 and the following works for me

#include <windows.h>
#include <stdio.h>

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    try
    {
  char *p = NULL;
  strcpy(p,"Good luck");
  MessageBox(NULL, "Not Working", "Uh Oh", MB_OK);
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
 {
  switch(GetExceptionCode())
  {
   default:
    MessageBox(NULL, "Unhandled Exception.", "Exception", MB_ICONERROR);
  }
 }
 return 0;

Quote
}

Other Threads