c# debugger noce ujeti exceptiona!!

uporabljam VS2008

zadnje case se mi precej to dogaja da debugger noce ujeti exceptiona. Posebej bedno je zato ker kar prekine izvajanje sredi kode sredi funkcije in nic - potem kar lepo vse naprej kot da ni nic ... form se vedno lepo narej laufa in samo nic se ne zgodi kar bi morala tista funkcija narediti - in ce je misljeno da se , kar s emora izvesti, izvede zadaj brez da se nekako pokaze na ekranu - potem sploh ne vem da se ni izvedlo!!....

da zdaj malo bolj konkretno razlozim in dam primer:

ker veliko uporabljam drag and drop operacije (dropnem fajle v textbox recimo) ki potem klicejo eventhandlerje sumim da je nekje tu fora


ja evo sem naredil se par testov... torej:
ce pozenem funnkicjo ki notri recimo ima

long l = long.Parse("blabla"); //jasno parse ne dela

lepo ujame debugger exception...in vse ok

...
ce pa isto funkcijo pozene DragDrop eventhandler od textboxa (ki ga invokea ta textbox ko dropnem fajl not) - pa preprosto vrze ven iz funkcije funkcija ko pride do parse operacije ... in nic ne javi sploh .. vse dela normalno naprej


ce dam try catch okoli parse ukaza potem deluje... ampak kaj a zdja moram vse try catch... sem mislil da se lahko na debugger zanasam


hvala za pomoc... me prav zanima kaksna je teorija tukaj zadaj

ok super... zdaj ujame..

ampak!! ko buildam in pozenem brez debugerja mi pri navadnem callu parse funkcije windows pribije error in end taska zadevo... ce pa spet preko drop eventhandlerja poklice funkcijo pa nikjer nobenega errorja... samo spet se ne izvede funkcija do konca....

torej a se da scompilat zadevo tako da bodo windowsi pribili error... ali moram zdaj vedno zadevo poganjati skozi debugger... kaj bo pol ko bom hotel release build poganjat in ne bom mel pojma kaj se dogaja zadaj....




no.... to zajebavanje debuggerja me je na se neko idejo napeljalo....
sprasujem se ce je "addanje to list" thread safe in ce pribje exception...

recimo ce 1000 threadov adda iteme v list ... a lahko pride do kaksnega konflikta in, da ne pribije nobenega exceptiona in, da se samo prekine operacija addanja - in pac kaksen objekt ni addan -brez da bi jaz kaj vedel o tem

in kaj je recimo z funkcijo List.AddRange() ... kaj ce vec threadow addaRange naenkrat... kako se addajo not elementi - a vsak "range elementov" pride notri kot celota.. ali se kot zadrga razlicni "rangei elementov" prepletejo med sabo



btw darko... ti odgovoris na skoraj vsa moja vprasanja tukaj na slotechu.... a si full time c# programer al kaj...ali si slovenski microsoft support guy zadolzen za slotech in forwardas vrpasanja nekim microsoft ljudem v ameriki in potem preneses odgovore...

brez sinhronizacije ne, niti ne rabi bit multicore racunalnik

ok.. kaj je ta sinhronizacija v c#.. lock statmenti?


in kakoje z List.Add() in List.AddRange()...
a kdo ve?

@arjan_t: nisi pozorno prebral, kar sem napisal, zato si napisano narobe razumel.

err a je originalno vprasanje
-ali bos videl tako natancne errorje kot jih dobis ko zadevo laufas v debug modu v visual studijo tudi...ko bos program tekel samostojno v release modu?
ne...ne bos.se posebi ce mas nastavljeno opcijo, da odstrani vso debug kodo(omit debug...smth...ne spomnim se imena nastavitve)...in ta je po defaultu v release modu izklopljena.
resitev je da zadevo logiras v file ob exceptionih(to ne pomen da das vsako kodo v try catch block...ampak samo tisto, kjer ti nimas vpliva nad dogajanjem in jo je treba pohendlat...npr...sql query)
priporocam, da uporabljas log4dotnet.

kar se tice sinhronizacije v c#...je najbl osnovn in cheap nacin isti kot v vb.netu

vb.net:
SyncLock(ArrayLista)
...karkol ze hocs threadsafe delat na tej arraylisti

End SynLock

c#
lock(ArrayList)
{

...karkol ze hocs threadsafe delat na tej arraylisti
}

TO al pa uporabis Semafor class (System.Threading.Semaphore)

vb.net

Dim s as new System.Threading.Semaphore(1,1)

s.WaitOne
...karkol ze hocs threadsafe delat na tej arraylisti
s.Release

...v c#-u je isto...sam pac v c#-u napises kodo :P

za kj bl kompleksnega mas pa mutex class.
V bistvu ti priporocam da si na www.codeproject.com poisces multithreading howto (mas 2...en ma ene 5 clankov ta drug pa trenutno sam 1-2)...oba ti bosta pa vse razlozila.

Na single core x86 arhitekturi je i++ za Int32 še relativno varno, ker se to prevede v en strojni ukaz, ki se ga med izvajanjem ne da prekiniti.

Seveda te pa to na MP platformi takoj ugrizne... kar pomeni, da če uporabljaš več niti, moraš vedno paziti na sinhronizacijo. Še posebej pa pri kakšnih mutable razredih.

zelo odvisno , če i++ uporabljaš v for statementu potem tudi na single core a multi thread applikaciji ni varen(i++ je a for ni več). vsaj v c-ju to še vedno velja , a tudi v c# ne vidim kako bi detektiral atomičnost expressiona je preveč imperativna zadeva.

je pa lahko naprimer index v arrayu. (najbolj tipična napaka katero opažam).

Na single core x86 arhitekturi je i++ za Int32 še relativno varno, ker se to prevede v en strojni ukaz, ki se ga med izvajanjem ne da prekiniti.

Tega nikakor ne moreš trditi v nobenem primeru. Noben del C++ standarda ti ne zagotavlja, da je i++ sploh atomična operacija in se na atomičnost le-te ne smeš nikakor zanašati.

Duh! Česa ne more trditi? Da se pod natančno določenimi pogoji zgodi natančno določena posledica? Seveda lahko. Običajno s katastrofalno posledico za pravilnost delovanja aplikacije, ko prispe do sistema kjer ti nujni pogoji niso izpolnjeni.

Ti pa govoriš in parafraziraš nekar s čemer se popolnoma strinjam... in sem povedal tudi že v originalni objavi. Naj še enkrat ponovim z drugimi besedami:

Zaradi določenih arhitekturnih lastnosti in okolja izvajanja lahko napišeš nepravilen program, ki bo zaradi teh določenih predpogojev deloval pravilno. Seveda pa bo program še vedno nepravilen, kar se bo slej kot prej vrnilo in te ugriznilo v r*t.

In to je bistvena lekcija pri prevelikem zanašanju na razhroščevalnike. Če tega nisi tako prebral, potem sem verjetno trditev zapisal preveč jedrnato. Škoda, da si že drugi, ki se je zataknil ob en stavek, ki je vzet iz konteksta. Ali res pišem tako nerazumljivo?

Ah, pa mimogrede: tema je C# in ne C++. Čeprav je v tem primeru razlika popolnoma nepomembna. Lahko bi bil tudi Delphi ali pa C.