Poszukiwany mfc140d.dll dla Visual Studio 2017

Witam, poszukuję podpowiedzi skąd pobrać mfc140d.dll dla Visual Studio 2017, podczas debugowania dostaję błąd pokroju:

kiedy go zignoruję mogę sobie debbugować dalej.

Dodam, że dzieje się to tylko wtedy, gdy CRecordset ma rzucić wyjątkiem, że np. nie udało się poprawnie wykonać zapytania sql-owego lub nie istnieje dana kolumna.

Jeśli możesz debugować to masz ten plik zainstalowany z VS. Ten typ błędu to prawdopodobnie out-of-bound access na jakimś kontenerze standardowym - zobacz przy jakiej operacji w twoim kodzie jest wywoływany (np. przy operatorze []?)

Wywoływany jest wtedy, jeżeli próbuję CRecordset::GetFiledValue wyjść po za zakres, np. select zawiera 2 kolumny, a ja próbuję "siegnąć" 3 kolumnę, bądź zrobiłem literówkę przy nazwie kolumny, o którą pytam.

Co ciekawe, złapałem to w blok try-catch i w release nie ma problemu, wyjątek jest prawidłowo łapany i treść błędu SQL-a także, natomiast taka sytuacja ma miejsce podczas debugowania

BartoSAS napisał(a):

Co ciekawe, złapałem to w blok try-catch i w release nie ma problemu, wyjątek jest prawidłowo łapany i treść błędu SQL-a także, natomiast taka sytuacja ma miejsce podczas debugowania

Debugger jest czasami nadgorliwy i zgłasza wyjątki nawet jeśli są one w kodzie łapane. Jeśli wyjątek ten nie jest na porządku dziennym (a nie powinien!) to po prostu go ignoruj podczas debugowania. Nic złego się nie dzieje.

tldr: nie wychodź poza zakres i nie rób literówek :)

BartoSAS napisał(a):

Co ciekawe, złapałem to w blok try-catch i w release nie ma problemu, wyjątek jest prawidłowo łapany i treść błędu SQL-a także, natomiast taka sytuacja ma miejsce podczas debugowania

Jeśli dobrze rozumiem, to to właśnie ma tak działać – w debug pojawia się komunikat z informacją o wyjątku i można podjąć odpowiednią akcję, natomiast w release wyjątek jest łapany, obsługiwany i program dalej działa normalnie.

Czyli VS zachowuje się dokładnie tak samo jak Delphi czy Lazarus – nic nadzwyczajnego.

@Azarien: robiłem smutny wrapper na CRecordset, żeby było wygodniej robić zapytania :/
@furious programming niewykluczone, ale Señor developer uznał, że to niedopuszczalne, bo wcześniej na gołych wskaźnikach nie było takich reakcji, więc try-catch do zezłomowania pójdzie prawdopodobnie :(

Zamiast try/catch po prostu nie wywołuj funkcji na nieistniejących indeksach...

BartoSAS napisał(a):

Co ciekawe, złapałem to w blok try-catch i w release nie ma problemu, wyjątek jest prawidłowo łapany i treść błędu SQL-a także, natomiast taka sytuacja ma miejsce podczas debugowania

W trybie budowania Debug na Visual studio std::vector::operator[] sprawdza zakres indeksu i rzuca wyjątkiem za pomocą asercji!
Ten wyjątek, to jest nie jest wyjątek C++, więc try catch nic tu nie da, to jest asercja w stylu C, która natychmiast zatrzymuje program.

W trybie budowania release std::vector::operator[] nie robi sprawdzania i wtedy dostęp do indeksów z poza zakresu jest po prostu Niezdefiniowanym Zachowaniem (może zdarzyć się cokolwiek, w tym nic).
Ergo kq dobrze ci mówi, masz poważny błąd w programie, który MUSISZ naprawić.

Odpal program z IDE w trybie debugwania (F5) (bo to co pokazujesz to jest normalnie włączony program, który jest zbudowany pod Debug) i jak się pojawi błąd to przeanalizuj Call Stack.

Albo jeśli wolisz swoją metodą, to jak wyskoczy ci to okienko, to wtedy naciśnij "Ponów", zgódź się na debugowanie i wybierz właściwa instancję VS. Wtedy też przeanalizuj Call Stack.

W Visual Studio można ustawić na jakie wyjątki powinien reagować Debugger. Ale to nie jest wyjątek w rozumieniu C++.

Dla sprostowania, bo może się nie zrozumieliśmy: sytuacja w której to się dzieje:

CRecordset rs(&db);
// Powiedzmy, że są 2 kolumny w tej tabeli
rs.Open(CRecordset::forwardOnly, _T("SELECT * FROM Customer"));

// Create a CDBVariant object to
// store field data
CDBVariant varValue;

try
{
// Błąd w sztuce, nie ma takiej kolumny
rs.GetFieldValue("CUSTOMER_NAME", varValue);
}
catch (CDBException * exception)
	{
			exception->m_strError;
			exception->m_strStateNativeOrigin;
		return 0;
	}

IsEOF() zwraca true, bo jakieś rekordy istnieją, tyle tylko, że jak się ktoś pomyli, to w exception->m_strError znajduje się treść błędu, że "Kolumna o nazwie x nie istnieje".

@update -> IsEOF() zwraca false