[C#] truc: Bron van Object reference error vinden

[PdeBie]

Heren/dames ontwikkelaars,

Ik liep vandaag weer eens tegen de welbekende 'object reference is not set to an instance of an object' error aan. Iets is dus NULL wat niet mag.

Dit gebeurde op een moment waarbij ik met een object met een redelijk groot aantal properties en 'sub' objecten met elk ook weer een aantal properties.
Het was dus even flink puzzelen welke property er NULL was.

Zijn er tips/trucs om snel te kunnen vinden welke property of welk object er NULL is i.p.v. met het handje in debug mode alles na te lopen?

[beany]

Als je tegen de error aanloopt breakt de debugger toch op de plek waar de property wordt aangeroepen? Dan zie je gelijk op welke property het mis gaat... of ontgaat mij hier nu iets?

[Grijze Vos]

op strategische plekken ArgumentNullExceptions gooien.

[Russel88]

Je weet toch in welke regel dat gebeurd?
In VS heb ik altijd het vinkje "thrown" bij Common Language Runtime Exceptions aanstaan. Dan blijft de exceptie op de juiste regel staan. En dan is het gewoon met de muis over je properties gaan.

[PdeBie]

beany schreef op woensdag 15 mei 2013 @ 15:49:
Als je tegen de error aanloopt breakt de debugger toch op de plek waar de property wordt aangeroepen? Dan zie je gelijk op welke property het mis gaat... of ontgaat mij hier nu iets?

In mijn geval gebeurde het op een datacontext.InsertOnSubmit in een Linq2Sql omgeving.
En een van de properties van de geneste objecten bleek NULL.

Grijze Vos schreef op woensdag 15 mei 2013 @ 15:49:
op strategische plekken ArgumentNullExceptions gooien.

Klopt, doe ik ook. Alleen het kan zijn dat het toch een keer ergens vergeten word.
Binnenkort krijg ik (eindelijk!) een Jetbrains Resharper licentie en die wijst je erop.

[sig69]

pdebie schreef op woensdag 15 mei 2013 @ 15:58:
[..]
Klopt, doe ik ook. Alleen het kan zijn dat het toch een keer ergens vergeten word.
Binnenkort krijg ik (eindelijk!) een Jetbrains Resharper licentie en die wijst je erop.

Ook niet altijd hoor, dat hangt er maar net vanaf of ie kan herleiden waar je object vandaan komt.

C#:

var x = entityMeuk.FirstOrDefault();
string s = x.ToString(); // Hier zeurt R# wel

string test(object o)
{
  return o.ToString(); // Hier niet
}

En verder hebben we ook nog Debug.Assert();

[ZpAz]

pdebie schreef op woensdag 15 mei 2013 @ 15:58:
[...]


In mijn geval gebeurde het op een datacontext.InsertOnSubmit in een Linq2Sql omgeving.
En een van de properties van de geneste objecten bleek NULL.


[...]


Klopt, doe ik ook. Alleen het kan zijn dat het toch een keer ergens vergeten word.
Binnenkort krijg ik (eindelijk!) een Jetbrains Resharper licentie en die wijst je erop.

In Xcode (en volgens mij ook in Eclipse) kan je breakpoints vuren op het moment dat 'exception x' gegooid wordt. Dan stopt hij netjes waar zo'n exception gegooid wordt.

[Russel88]

ZpAz schreef op woensdag 15 mei 2013 @ 16:28:
[...]


In Xcode (en volgens mij ook in Eclipse) kan je breakpoints vuren op het moment dat 'exception x' gegooid wordt. Dan stopt hij netjes waar zo'n exception gegooid wordt.

[afbeelding]

Heb je ook in Visual Studio: Debug -> Exceptions.

[RobIII]

ZpAz schreef op woensdag 15 mei 2013 @ 16:28:
[...]


In Xcode (en volgens mij ook in Eclipse) kan je breakpoints vuren op het moment dat 'exception x' gegooid wordt. Dan stopt hij netjes waar zo'n exception gegooid wordt.

[afbeelding]

Dat doet VS ook, maar het is wat lastig als de exception in 3rd party code gegooid wordt hé? (Linq2SQL gooit uiteindelijk de exception omdat pdebie, klaarblijkelijk, ergens een null in een object heeft staan dat 'ie in de DB probeert te proppen. Dan krijg je op de "Db.Insert(myObject)" een exception waar VS netjes op breaked, maar weet je nog steeds niet welk van de (potentieel) 1602 properties null is van MyObject ).

[ Voor 5% gewijzigd door RobIII op 15-05-2013 16:34 ]

[Russel88]

Mmhhh als je daar vaak last van hebt, zou ik een functie maken die met reflectie properties ophaalt en degene die value null heeft retourneren. Dan kun je die functie uitvoeren in je immediate window.

Zo'n functie bouwen gaat waarschijnlijk sneller dan door je 1602 properties heen loopen

[Feanathiel]

Mocht je het écht niet meer weten, dan kun je altijd nog DotPeek van JetBrains (die van Resharper) voor visual studio gebruiken. Deze zorgt ervoor dat de 3rd party library voorzien wordt van pdb bestanden (door decompilatie) waardoor de door de library kunt steppen.

Voor de rest moet je volgens mij gewoon een exception kunnen debuggen die je zelf veroorzaakt. Zorg je zelf voor de NullRef, dan moet je ook op deze kunnen breaken. Initieel kom je door je eigen code heen, waar vervolgens de library wordt aangeroepen. Deze vraagt properties/methoden uit die je zelf gemaakt hebt. Een trigger op de NullRefException moet volgens mij voldoende zijn. Wordt de exception in de library zelf veroorzaakt, dan is het een ander verhaal. Dan kun je dus bijvoorbeeld met zaken als DotPeek aan de gang, maar op zich is het dan ook wel een bugreportje waard aan de maker van de library (tenzij gedocumenteerd).

[ Voor 9% gewijzigd door Feanathiel op 15-05-2013 17:01 ]

[sig69]

Doe maar eens diverse inserts en updates op een Entity Framework datacontext en roep dan SaveChanges() aan, succes!

[RobIII]

Russel88 schreef op woensdag 15 mei 2013 @ 16:54:
Mmhhh als je daar vaak last van hebt, zou ik een functie maken die met reflectie properties ophaalt en degene die value null heeft retourneren. Dan kun je die functie uitvoeren in je immediate window.

Zo'n functie bouwen gaat waarschijnlijk sneller dan door je 1602 properties heen loopen

BugAid gebruiken gaat nog sneller dan zelf dingen maken

[Feanathiel]

sig69 schreef op woensdag 15 mei 2013 @ 17:10:
Doe maar eens diverse inserts en updates op een Entity Framework datacontext en roep dan SaveChanges() aan, succes!

Werkt opzich prima toch?
http://imgur.com/Gif4Ljc (standaard)
http://imgur.com/ntxfb5D (break on first chance nullref)

[RobIII]

Feanathiel schreef op woensdag 15 mei 2013 @ 18:01:
[...]


Werkt opzich prima toch?
http://imgur.com/Gif4Ljc (standaard)
http://imgur.com/ntxfb5D (break on first chance nullref)

C#:

var c = new Customer() {
  FirstName = null,
  LastName = null
};

foo.Insert(c);

Als je dan een not-null constraint op je Firstname/Lastname fields hebt kun je debuggen wat je wil, de exception zal ergens in Insert() gethrowed worden. En als dat 3rd party code is waar je niet bij kunt is 't dus lastig debuggen als je 450 customers probeert te updaten/insterten. Dat is waar pdebie 't over heeft als je 't mij vraagt.

[PdeBie]

het is geen 3rd party code, maar inderdaad in de Insert. Ik heb een of meerdere Order objecten, met aan elk een tweetal OrderPerson objecten gekoppeld (afzender en besteller) en OrderItems (1 of meerdere artikelen).

Elk van die objecten hebben ook weer properties en geneste objecten. Nu heb ik het voor deze keer makkelijk kunnen ontdekken. Het orderitem had een null value in een property die geen null mocht zijn. Maar voor hetzelfde geldt is het in een van de geneste objecten. Dan kan je wel even zoet zijn met zoeken.

[ Voor 6% gewijzigd door PdeBie op 15-05-2013 22:17 ]

[RobIII]

pdebie schreef op woensdag 15 mei 2013 @ 22:16:
Dan kan je wel even zoet zijn met zoeken.

RobIII in "\[C#] truc: Bron van Object reference error vinden"

[Russel88]

RobIII schreef op woensdag 15 mei 2013 @ 17:52:
[...]

BugAid gebruiken gaat nog sneller dan zelf dingen maken

Mmmhh een keertje testen.
Het klote van zulk soort software is dat het soms best een belasting kan zijn op je resources. Maar toch een keertje installeren om te zien of dit wat is, ken het niet. En effe opzoeken waar ik mijn mvp gegevens heb

[sig69]

RobIII schreef op woensdag 15 mei 2013 @ 23:23:
[...]

RobIII in "\[C#] truc: Bron van Object reference error vinden"

Is dat nu al een keer wat? Laatste keer dat ik het geprobeerd heb (maaaaanden geleden) was het niet vooruit te branden, en samen met R# werd m'n systeem toch wel aardig onwerkbaar. Vind het er nog steeds wel interressant uit zien.