|
Could someone help me to understand, " When the code in a try block does not throw an exception, which of the following is false?"
1. all the catch handlers immediately following the try block are skipped
2. execution resumes with the first line of code after the catch handlers
3. a default exception is thrown
4. none of the function calls within the try block threw an exception
Thanks, Moujan
|
|
|
|
|
Could you have at least bothered to format this question so that it was not screaming
HOMEWORK!
How about spending a few hours studying up on what a try /catch block is/does? Is your education not worth at least that much effort?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
If I would know what a try block is, I would be able to answer the question. I wrote could someone help me to understand what the try block is and give the 4 choices. I didn't ask for the answer, but I ask for understanding the concept. You could it give suggestion what try block. Thanks David
|
|
|
|
|
|
Sorry David i wanted to give 5 but by mistake pressed 1.
Sorry Again.
Regards,
FarPointer
Blog:FARPOINTER
|
|
|
|
|
David, I really didn't mean anyone give me an answer. I posted the question as it was stated to show what I am looking for since I don't know what try block is.
However, I looked through the posting and it seems most of them are homework questions but in a different way. If I offended anyone I am sorry.
Thanks for suggestions, Moujan
-- modified at 15:27 Monday 26th June, 2006
|
|
|
|
|
Moujan wrote: If I offended anyone I am sorry.
I can't speak for others, but I would hardly get offended at someone for asking a homework question. I was simply pointing out to you what a better protocol would be.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
While it would be very easy to tell you the answer to your homework problem, it wouldn't help you much to do so. Instead, go to Bjarne's book (The C++ Programming Language) and use the index to look up "try-catch", "exceptions", and "exception handling".
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac, you don't need to be rude. I explained it in my earlier respond.
Thanks, Moujan
|
|
|
|
|
Rude? What part of that response was rude?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
1 is true
2 is usually true, however I think it's legal to goto out of a try block, in which case execution resumes at the target of the goto
3 is false - there's no such thing
4 cannot be determined. A function called in a try block may have thrown an exception, but contained a catch that caught and processed the exception.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
Thanks Mike for the explenation.
I still don't know when we use "try block" and why (this is not a homework question)! It is not in my assignments, so I don't know and I like to learn.
Thanks again,
Moujan
|
|
|
|
|
|
The answer is language dependent.
"Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
|
|
|
|
|
Hi,
Does anyone have experience on this issue. I tried to call a vc++ 6 FMC dll from a regular vc++6 dll. I got a link error "afxcw.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in usersec32.obj", where usersec32.obj is the calling object. It seems to me _DllMain is defined in both dll.
I am wondering whether it is possible to call a dll from a dll. If possible, what do I have missed?
Very appreciate if I get assistance. Thanks in advance.
hli
hli
|
|
|
|
|
Are using that header file or other dll for compilation? or loading using "GetProcAddress" ???
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
I inserted a line #include "secondDll.h" in the first dll. It caused the link error. This worked for calling a dll from .exe file.
#include <stdio.h>
#include <cmath>
#include "secondDll.h"
hli
|
|
|
|
|
Sorry, my code is
#include <stdio.h>
#include <cmath>
#include "dbInsert\DBArea.h"
hli
|
|
|
|
|
The previous posts do not display the #include values. They should be: #include <stdio.h> and #include <cmath>
hli
|
|
|
|
|
that is the problem. when it is linking, with other lib file, it is seeing there are two dll main functions(its own and others).
Try using loadlibray and GetProcAddress it will resolve your problem.
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
Many thanks. May I have a brief sample code for that.
hli
|
|
|
|
|
Or just include the header files for the classes you intend to use instead of the main header for the DLL.
You don't have to use LoadLibrary/GetProcAddress to call methods from one DLL in another. You just have to make sure that both DLLs are built with the same threading library and you properly include header files and link with the libs.
As a side note, make sure you don't create cross-dependencies between DLLs when doing this ... they are NOT fun to work with.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Hi,
Thank both of you first. I am wondering that in my case I have to use LoadLibrary/GetProcAddress. I am attaching the example below which caused the link error. Please let me know if I can use Zac's suggestion instead of LoadLibrary/GetProcAddress approach.
A head file in the second dll project is named as DBArea.h. There are several classes in the second dll that are defined in dataWork.h. So dataWork.h is included in the DBArea.h file. The first dll is designed to use member functions "rowInsert" and "getConnection" in class DBArea.
#include "dataWork.h"
#if !defined(AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_)
#define AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_
#if _MSC_VER >> 1000
#pragma once
#endif // _MSC_VER >> 1000
class DBArea
{
public:
__declspec(dllexport) int rowInsert(char *SQLStr);
__declspec(dllexport) int GetConnection(char *connectionStr);
__declspec(dllexport) DBArea();
__declspec(dllexport) virtual ~DBArea();
protected:
CADORecordset m_pRs;
CADODatabase m_pDb;
};
#endif // !defined(AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_)
hli
|
|
|
|
|
For starters, when you include this file in the DLL that will be calling into it, the __declspec(dllexport) should be changed to __declspec(dllimport). Typically, this is done by defining a macro that checks to see if the file is being compiled as a DLL or as an application; however, since both will be DLLs, you may need to define another macro that doesn't depend on that to check to see which is should use.
Second, you should __declspec the class, not individual methods. You will have a hard time calling these methods because they are exported, but they are part of a class that isn't exported.
Just FYI, you almost never "have" to use LoadLibrary/GetProcAddress. The only time you have to do so is when your requirements call for late-binding DLLs, and even then, there are some other options.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|