Výjimky a DLL, nerozumím – .NET – Fórum – Programujte.com

Ahoj,

marně si lámu už dva dny s následujícím problémem.

Vyvíjím tu jednu souborovou aplikaci, ta se bude spouštět jako konzolová, tak i jako okenní. Společné jádro programu je v DLL knihovně a prakticky konzole i DlgApp jen volají hlavní třídu knihovny. Program mj. používá i .NET Connector pro mySQL.

Protože jde o jednoduchou utilitu bez instalace, musí být ošetřená i na případ, že jí chybí příslušná DLL a toto nějak srozumitelně sdělit. Proto oba programy mají základní try-catch kolem volání hlavní DLL a v případě chyby to oznámí uživateli a zároveň zapíšou do LOGu pro odeslání.

A teď k problému. Pokud smáznu hlavní společnou knihovnu, obě aplikace zareagují v pořádku podle očekávání. Jakmile ale vyhodím knihovnu mySQL, tak konzolová aplikace zařve chybu, uloží LOG a skončí. Naproti tomu DlgApp spadne na neošetřenou výjimku a nedaří se mi za nic přijít na to proč. Ke všemu když zkusím aplikaci krokovat, proběhne koretní zobrazení dialogu s chybou a konec. WTF?

Tak bez kodu ti toho asi moc nereknem :).

Jinak sem moc neslysel ze by se delalo osetrovani na chybejici zakladni soubory aplikace. Jako chapu kdyz je modularni ale moc nevidim smysl kontrolovat zakladni soubory.

No prvne se ptam obecne, nez sem upravovat kod - treba to mezi DLL volanim funguje jinak, nevim...

Jinak zadne soubory se na existenci nekontroluji, jde jen o to, aby aplikace skoncila nejak srozumitelne a uzivatel mel aspon zaznam v souboru ze ktereho poznam co bylo za problem. To je IMHO std. pozadavek na vsechny nepredvidatelne chyby, nejen chybejici komponenta.

Podle me se ma vetsinou resit jen to "aby aplikace skoncila nejak srozumitelne" coz podle me neni ten pripad ze se ani nespusti   .

To co te teda asi bude zajimat sou 2 eventy.

AppDomain.AssemblyResolve - kdyz vytvaris instanci typu nebo volas staticke fce tak se hleda v jakem dll je ten typ a pokud se to dll nenajde tak se vola tenhle event. ( http://msdn.microsoft.com/….110%29.aspx )

AppDomain.UnhandledException - proste kdyz to nekde spadne a nechytis to tak se vola toto. ( http://msdn.microsoft.com/….110%29.aspx )

#4 p3can
"coz podle me neni ten pripad ze se ani nespusti"

V tom ti musím oponovat, ono není nad telefonát typu "mě to nefunguje", "a co to dělá?", "nic, nevím... cosi nesrozumitelnýho anglicky a čísílka, je tam toho hodně",.... Místo "píše mě to chybnou instalaci"   

Jinak eventy jsem zkusil, ale chová se to úplně stejně. - resp. stejně jako normálního odchytávání výjimek. Tuším, že tady to funguje nějak jinak.

Konzolová aplikace:

static void Main(string[] args)
		{
			try
			{
				CallDLL(args);
			}
			catch (Exception ex)
			{
				// výpis neošetřené chyby na konzolu a do textového souboru
				String error = String.Format("Chyba: {0}\n{1}\n", ex.GetType().ToString(), ex.Message);
				String erlog = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments) + @"\error.log";
				Console.WriteLine(error);
				try
				{
					using (StreamWriter objSw = new StreamWriter(erlog, true, Encoding.UTF8))
					{
						objSw.WriteLine(String.Format("{0}\n{1}", DateTime.Now.ToString("dd.MM.yyyy HH:mm:ss K"), error));
						objSw.Flush();
						objSw.Close();
						Console.WriteLine("Text chyby byl uložen do souboru: {0}", erlog);
					}
				}
				catch
				{
					Console.WriteLine("Selhal pokus o uložení do LOGu {0}", erlog);
				}
			}
		}

GUI aplikace (to stejné)

static void Main()
		{
			Application.EnableVisualStyles();
			Application.SetCompatibleTextRenderingDefault(false);

			try
			{
				CallDLL();
			}
			catch (Exception ex)
			{
#warning pro nedostupnou sharelib funguje, ale při smazání sql dll
				// výpis neošetřené chyby do dialogu a do textového souboru
				String error = String.Format("Chyba: {0}\n{1}\n", ex.GetType().ToString(), ex.Message);
				String erlog = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments) + @"\error.log";
				try
				{
					using (StreamWriter objSw = new StreamWriter(erlog, true, Encoding.UTF8))
					{
						objSw.WriteLine(String.Format("{0}\n{1}", DateTime.Now.ToString("dd.MM.yyyy HH:mm:ss K"), error));
						objSw.Flush();
						objSw.Close();
						MessageBox.Show(error + String.Format("\nChyba uložena do logu: {0}", erlog), "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
					}
				}
				catch
				{
					//Console.WriteLine("Selhal pokus o uložení do LOGu {0}", erlog);
					MessageBox.Show(error + String.Format("\nSelhal pokus o vytvoření logu: {0}", erlog), "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
				}
			}

		}

A vstupní metoda sdílení DLL

public void Run()
		{
			try
			{
				// ... společný kód
			}
			catch (MyException ex)
			{
				msg.Error(ex.Get_Error_Msg());
				Environment.Exit(ex.Err_code);
			}
			catch (MyDebugException ex)
			{
				msg.Error(ex.Get_Error_Msg());
				ExitException(GlobalSet.EXITCODE_DEBUG_EXCEPTION);
				Environment.Exit(GlobalSet.EXITCODE_DEBUG_EXCEPTION);
			}

Pointa je v tom, že když do DLL knihovny doplním ještě "catch (Exception ex)", tak to odchytne i chybu v SQL, ale v tomto tvaru výjimka prostě "neprobublá" až nahoru ke spouštěcí aplikaci.

Jinak řečeno řešení už mám, ale nevím proč se to takto chová..  

Ja myslim, ze to dela Visual Studio debugger. Zkus to zbuildovat jako Release a spustit to normalne, ne z VS.

Vyzkoušeno - nedělá. Debug i Release, spouštěno z průzkumníka pořád stejné. U konzoly zachytí a vypíše, u GUI spadne bez zachycení.

Asi to odložím do šuplíku záhad, fakt nevím co s tím...

Ahoj, možná je to blbost, ale napadlo mne: okenní aplikace (Winforms) používají tzv. partial classes. Prostě máš kód jedné třídy rozdělený do dvou souborů, jeden je editovaný programátorem a v druhém je kód vygenerovaný návrhářem. Toto se u konzolových aplikací nepoužívá. Není možné, že k chybě dochází v tom vygenerovaném kódu, kde nejsou ošetřené vyjímky? Nebo v tom vygenerovaném kódu může být nějaká reference, se kterou nepočítáš.

Ale je to jen nápad.

#8 RomanZ
Zní to logicky, ale v tom to nebude - spouštějící aplikace zareaguje naprosto v pořádku, pokud vyhodím hlavní sdílenou DLL. Ta nezachycená výjimka nastává až v případě, když sdílená knihovna volá SQL Connector a to je úplně mimo té hlavní aplikace.