[c#] null terug krijgen als instancieren van object mislukt

[shades]

Ik wil het volgende voor elkaar krijgen:

C#:

MijnObject mijnObject = new MijnObject(parm1, parm2, parmx);
if (mijnObject != null)
{
   // ga verder
}

Probleem is dat in de constructor van MijnObject checks worden gedaan. De check kijken of MijnObject wel of niet gebruikt kan worden.

C#:

public MijnObject(string parm1, string parm2, string parmx)
{
   if (parm1 != "test")
   {
      // object moet null terug, mag niet geinstancieert worden
   }
}

"return null;" werkt dus niet. Iemand een idee hoe dit zit. Waarschijnlijk is de oplossing vrij eenvoudig maar ik kom er niet uit. Kan iemand mij hierbij helpen ?

[jelmervos]

Gebruik maken van een class function (static) ipv de constructor?

[ Voor 17% gewijzigd door jelmervos op 11-01-2007 10:14 ]

[bigbeng]

Dit lijkt me typisch iets wat je met exception handling kan regelen. Gewoon een exception gooien in de constructor van je object en afvangen in de aanroeper.

Eventueel kun je zelf een zinvolle exception class maken (bv InstantiationNotAllowed of zoiets).

edit:
Ik lees net hier (helaas uit de cache van google) dat je moet uitkijken met unmanaged resources en het gooien van exceptions in de constructor van een object.

[ Voor 38% gewijzigd door bigbeng op 11-01-2007 10:24 ]

[Jaap-Jan]

Gewoon "return;" gebruiken, al is een exception throwen ook geen slecht idee, zoals hierboven word gezegd .

[ Voor 61% gewijzigd door Jaap-Jan op 11-01-2007 10:20 ]

[MTWZZ]

Wat je hier wil doen is een ArgumentException gooien. Je bent immers bezig met het validaten van je argumenten en je wil absoluut niet dat je object gebruikt gaat worden met brakke argumenten dus is een Exception op z'n plaats.

[whoami]

bigbeng schreef op donderdag 11 januari 2007 @ 10:17:
Dit lijkt me typisch iets wat je met exception handling kan regelen. Gewoon een exception gooien in de constructor van je object en afvangen in de aanroeper.

Eventueel kun je zelf een zinvolle exception class maken (bv InstantiationNotAllowed of zoiets).

edit:
Ik lees net hier (helaas uit de cache van google) dat je moet uitkijken met unmanaged resources en het gooien van exceptions in de constructor van een object.

exceptions moet je zowiezo niet gebruiken om je program-flow te bepalen. 't Is trouwens duur, exceptions gooien.

Het is gewoon beter om -zoals in de eerste reply al aangegeven werd- om hier een factory method voor te gebruiken. In die method ga je dan checken of je je object kan creeëren, en indien het niet kan, return je NULL, anders return je je object.

MTWZZ schreef op donderdag 11 januari 2007 @ 10:26:
Wat je hier wil doen is een ArgumentException gooien. Je bent immers bezig met het validaten van je argumenten en je wil absoluut niet dat je object gebruikt gaat worden met brakke argumenten dus is een Exception op z'n plaats.

Men verwacht van een constructor dat hij je object in een valide staat creeërt. Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performatner.

Jaap-Jan schreef op donderdag 11 januari 2007 @ 10:19:
Gewoon "return;" gebruiken, al is een exception throwen ook geen slecht idee, zoals hierboven word gezegd .

Dit doet niet wat de TS wil. Hij wil dan een NULL reference terugkrijgen, en dat gebeurt hier niet. Het enige wat hier wel gebeurt is dat je dan een object instantieert dat zich niet in een geldige state bevindt. En dat wil je al helemaal niet.

[ Voor 32% gewijzigd door whoami op 11-01-2007 10:39 ]

[TeeDee]

MTWZZ, thanks voor de extra uitleg. Bij de reactie van bigbeng dacht ik: ga je exceptions nu gebruiken voor je flow? Nu is de reactie van jullie beiden duidelijk

[ Voor 5% gewijzigd door TeeDee op 11-01-2007 10:36 ]

[_Thanatos_]

Ik sluit me erbij aan dat exceptions hier gewoon de aangewezen oplissing is. In de constructor:

C#:

public MijnObject(string parm1, string parm2, string parmx) {
   if (parm1 != "test")
      throw new ArgumentException("parm1");
}

En bij de instanciëring van je ie dan af:

C#:

try {
   MijnObject mijnObject = new MijnObject(parm1, parm2, parmx); 
   // ga verder (hier komt ie niet als de exception opgegooid was)
}
catch (ArgumentException) {
   // foutje
}

[ Voor 3% gewijzigd door _Thanatos_ op 11-01-2007 10:57 ]

[bigbeng]

Okee okee, een factory method is beter. Het argument dat je exceptions niet moet gebruiken om je program flow te bepalen snap ik, maar het was mij iig niet duidelijk dat dit perse aan de orde was. Als dat zo is, dan ben ik met whoami (en blijkbaar ook met TeeDee)

En de hogere kosten van een exception is alleen een argument in systemen waar performance een issue is.

[kenneth]

_Thanatos_ schreef op donderdag 11 januari 2007 @ 10:56:
Ik sluit me erbij aan dat exceptions hier gewoon de aangewezen oplissing is.

-->

whoami schreef op donderdag 11 januari 2007 @ 10:34:
Men verwacht van een constructor dat hij je object in een valide staat creeërt. Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performatner.

Waarom dan toch exceptions, Thanatos?

[TeeDee]

whoami schreef op donderdag 11 januari 2007 @ 10:34:
[...]
Men verwacht van een constructor dat hij je object in een valide staat creeërt. Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performatner.

Is dat geen gevaarlijke aanname? Zeker met het woord "verwacht". Maar ik zal eens kijken/zoeken naar de factory insteek.

kenneth schreef op donderdag 11 januari 2007 @ 11:00:
[...]Waarom dan toch exceptions, Thanatos?

Lijkt me dat dit een issue is die door de devver zelf gemaakt moet worden. Waar ik wel moeite mee heb is het feit dat er in de constructor al vrij veel checks gedaan worden. En dan kom je denk ik automatisch op een method / factory uit, verwacht ik. Hoewel een ArgumentException ook een plausibele oplossing is.

[ Voor 3% gewijzigd door TeeDee op 11-01-2007 11:04 ]

[MTWZZ]

whoami schreef op donderdag 11 januari 2007 @ 10:34:
Men verwacht van een constructor dat hij je object in een valide staat creeërt. Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performanter.

Ook een goeie oplossing. Het ligt er echter wel aan hoe je in de factory method je argument checking gaat aanpakken. ArgumentException gooien of null returnen. Als je echt op de performance aan het hameren bent is het natuurlijk null returnen en bij de factory aanroep nog checken op null. IMHO is het denk ik niet eens zo verkeerd om bij bepaalde classes een exception te gooien puur om de reden dat het exceptional is als het voorkomt dat er een verkeerd argument wordt meegegeven.

bigbeng schreef op donderdag 11 januari 2007 @ 11:00:
En de hogere kosten van een exception is alleen een argument in systemen waar performance een issue is.

Performance is altijd een issue. Misschien niet de belangrijkste (denk aan availability/stability) maar wel degelijk belangrijk.

Het argument dat je exceptions niet moet gebruiken om je program flow te bepalen

Exceptions geven wel degelijk een programma flow, een exceptionele flow. Even een voorbeeld:

Je gaat een deur open maken. Hierbij heb je 2 verwachte flows:
- De deur gaat open
- De deur gaat niet open (zit op slot)
Maar stel nou dat op het moment dat jij de deur open wil doen die zelfde deur in vlammen uitbarst?
Dan krijg je dus die exceptionele flow: je gaat de brandweer bellen. Het is namelijk niet een gewone uitkomst van MaakDeurOpen()

Hoewel de basis is dat je de exception niet je programma flow laat bepalen moet je er wel rekening mee houden.

[ Voor 39% gewijzigd door MTWZZ op 11-01-2007 11:17 ]

[shades]

Jaap-Jan schreef op donderdag 11 januari 2007 @ 10:19:
Gewoon "return;" gebruiken, al is een exception throwen ook geen slecht idee, zoals hierboven word gezegd .

Zie je wel.. zat er niet ver naast.

whoami schreef op donderdag 11 januari 2007 @ 10:34:
[...]

exceptions moet je zowiezo niet gebruiken om je program-flow te bepalen. 't Is trouwens duur, exceptions gooien.

Het is gewoon beter om -zoals in de eerste reply al aangegeven werd- om hier een factory method voor te gebruiken. In die method ga je dan checken of je je object kan creeëren, en indien het niet kan, return je NULL, anders return je je object.


[...]

Men verwacht van een constructor dat hij je object in een valide staat creeërt. Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performatner.


[...]

Dit doet niet wat de TS wil. Hij wil dan een NULL reference terugkrijgen, en dat gebeurt hier niet. Het enige wat hier wel gebeurt is dat je dan een object instantieert dat zich niet in een geldige state bevindt. En dat wil je al helemaal niet.

Altijd verhelderend !
Ik ben in iedergeval blij dat wat ik wil de juiste methode is. Ik heb namelijk zelf ook aan een argementexeption zitten denken maar als iets niet gemaakt kan worden moet ie gewoon null zijn.
Thx !

[pjvandesande]

whoami schreef op donderdag 11 januari 2007 @ 10:34:
[...]

exceptions moet je zowiezo niet gebruiken om je program-flow te bepalen. 't Is trouwens duur, exceptions gooien.

Exceptions horen je program-flow niet te bepalen, maar om nou gelijk te zeggen dat ze duur zijn is natuurlijk onzin.

Als je bijvoorbeeld de filesize moet specificeren bij een ctor overload, dan mag deze niet negatief zijn. Hiervoor kun je een uint pakken of het argument controleren en een ArgumentException gooien. Hier zijn Exceptions niet meer dan normaal.

HttpExceptions omhoog gooien is in ASP.NET gebruikelijk, bijvoorbeeld als content gemoved is. Hier past het dus wel binnen je program-flow.

Men verwacht van een constructor dat hij je object in een valide staat creeërt. Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performatner.

Toch is het vrij normaal om binnen je ctor Exceptions te gooien. Ook als je een factory method gebruikt roep je altijd nog een ctor aan. Ik wil er altijd zeker van zijn dat mijn object valid gecreeerd word en zal dan ook hier de argumenten checken.

[ Voor 23% gewijzigd door pjvandesande op 11-01-2007 11:26 ]

[MTWZZ]

pjvandesande schreef op donderdag 11 januari 2007 @ 11:24:
Toch is het vrij normaal om binnen je ctor Exceptions te gooien. Ook als je een factory method gebruikt roep je altijd nog een ctor aan. Ik wil er altijd zeker van zijn dat mijn object valid gecreeerd word en zal dan ook hier de argumenten checken.

Exactly! Je wil je toch indekken tegen het geval dat je constructor wordt aangeroepen zonder door de factory te lopen. (ok je hebt private en whatnot voor technieken om dit tegen te gaan, maar toch)

[.oisyn]

whoami schreef op donderdag 11 januari 2007 @ 10:34:
[...]

exceptions moet je zowiezo niet gebruiken om je program-flow te bepalen. 't Is trouwens duur, exceptions gooien.

Daarom moet je ook gewoon zorgen dat je object creëerbaar is (dus zorgen voor de juiste parameters en omstandigheden). Als dat niet zo is dan is dat een program error - een assert of exception is hier op z'n plaats

Men verwacht van een constructor dat hij je object in een valide staat creeërt.

Klopt

Ik zou nooit excepties gooien binnen een constructor; een factory method is hier netter en performatner.

Deze zin lijkt te maken te hebben met de vorige, maar ik zie niet waarom. Je kunt je object niet in een valide staat creëren (de parameters zijn onjuist), dus een exception is de enige uitweg.

Een factory method kan ook, maar ik zie niet in waarom dat beter is. Dan wordt de user opgescheept met irritante null checking die hij makkelijk kan negeren (dus je wordt niet meteen met de program error geconfronteerd). En als ie dan wel checkt, hoe weet ie dan wát er fout is gegaan? Hij weet alleen dát het fout is gegaan. Is het een verkeerde parameter? Of wordt het object op een verkeerd moment aangemaakt?

En hoe gaat je factory method ervoor zorgen dat objecten die MijnObject in de constructor aanmaakt ook allemaal lukken? Het is duidelijk niet de verantwoordelijkheid van die factory om daar ook voor te zorgen, daar zijn de subobjecten (of factories daar weer van) verantwoordelijk voor. Dan kun je in de factory wel de subobjecten aan gaan maken en die dan meepassen met de constructor van MijnObject, maar erg veel duidelijker wordt het er niet door.

Als je dan per se een null terug wil krijgen in sommige situaties, maak dan een non-throwing factory die je naast de constructor aan kunt roepen:

C#:

public static MijnObject TryCreateMijnObject(/* ... */)
{
    try
    {
        return new MijnObject(/* ... */);
    }
    catch(/*...*/)
    {
        return null;
    }
}

Performance is natuurlijk pas een argument als je duizenden objecten aan gaat maken met verkeerde parameters. Je kunt je afvragen of je dan überhaupt wel handig bezig bent.

[ Voor 4% gewijzigd door .oisyn op 11-01-2007 11:54 ]

[shades]

Jaap-Jan schreef op donderdag 11 januari 2007 @ 10:19:
Gewoon "return;" gebruiken, al is een exception throwen ook geen slecht idee, zoals hierboven word gezegd .

hej..
bij "return;" returned hij geen null maar gewoon MijnObject

Toch maar een exeception ?

[.oisyn]

lezen:

whoami schreef op donderdag 11 januari 2007 @ 10:34:
Dit doet niet wat de TS wil. Hij wil dan een NULL reference terugkrijgen, en dat gebeurt hier niet. Het enige wat hier wel gebeurt is dat je dan een object instantieert dat zich niet in een geldige state bevindt. En dat wil je al helemaal niet.

[shades]

.oisyn schreef op donderdag 11 januari 2007 @ 12:03:
lezen:

[...]

Ja.. blijft lastig he

Een factory method kan ook, maar ik zie niet in waarom dat beter is. Dan wordt de user opgescheept met irritante null checking die hij makkelijk kan negeren (dus je wordt niet meteen met de program error geconfronteerd). En als ie dan wel checkt, hoe weet ie dan wát er fout is gegaan? Hij weet alleen dát het fout is gegaan. Is het een verkeerde parameter? Of wordt het object op een verkeerd moment aangemaakt?

Liever dus een exception ?

---

Heb het volgende bedacht:

C#:

MijnObject mijnObject = null;

try
{
   mijnObject = new MijnObject(parm1, parm2, parmx);
}
catch {}

if (mijnObject != null)
{
   // ga verder
}

ctor van MijnObject:

C#:

public MijnObject(string parm1, string parm2, string parmx)
{
   if (parm1 != "test")
   {
     thrown new KanMijnObjectNietCreeerenException("fout melding");
   }
}

Al zou ik dit geval het hele stuk binnen if (mijnObject != null) ook direct in het try blok kunnen komen onder mijnObject = new MijnObject(parm1, parm2, parmx);

[ Voor 97% gewijzigd door shades op 11-01-2007 14:32 ]

[whoami]

.oisyn schreef op donderdag 11 januari 2007 @ 11:53:
[...]


Een factory method kan ook, maar ik zie niet in waarom dat beter is. Dan wordt de user opgescheept met irritante null checking die hij makkelijk kan negeren (dus je wordt niet meteen met de program error geconfronteerd).

IPV een NULL te returnen, kan je ook een NullObject returnen.

Ik ben het er wel mee eens dat je in je constructor nog eens extra kan checken of je een valid state zult verkrijgen, en indien niet een exceptie gooien.
Echter, als de topicstarter dan toch een null wil terugkrijgen, dan zal je zowiezo best af zijn met een factory method.

shades schreef op donderdag 11 januari 2007 @ 12:33:
[...]


Heb het volgende bedacht:

C#:

MijnObject mijnObject = null;

try
{
   mijnObject = new MijnObject(parm1, parm2, parmx);
}
catch {}

if (mijnObject != null)
{
   // ga verder
}

Excepties opeten ? Da's gewoon de struisvogel politiek. Er gaat iets fout en je steekt je kop in het zand.


En eigenlijk: je kan evengoed je class en je factory in eenzelfde assembly zetten, je constructor internal maken, en dan is de consumer van je assembly altijd verplicht om je factory te gaan gebruiken. Op die manier vermijd je ook duplicated logica. (eenmaal in je factory, en een keer in je constructor).

[ Voor 59% gewijzigd door whoami op 11-01-2007 14:59 ]

[whoami]

pjvandesande schreef op donderdag 11 januari 2007 @ 11:24:
[...]


Exceptions horen je program-flow niet te bepalen, maar om nou gelijk te zeggen dat ze duur zijn is natuurlijk onzin.

Helemaal geen onzin. Excepties zijn duur:
http://blogs.msdn.com/brada/archive/2004/01/09/49017.aspx
http://blogs.msdn.com/ricom/archive/2004/07/12/181091.aspx

Daarom bestaat er trouwens ook het Try... Do.. pattern (of hoe het ook alweer). Dat wil natuurlijk niet zeggen dat je excepties nooit mag gebruiken; gebruik ze in 'exceptionele' situaties. (In situaties dus waar een bepaalde toestand / operatie niet verwacht is / niet zou mogen optreden).
Het voorbeeld dat hier eerder aangehaald werd van die gesloten deur, is bv geen exceptie. Een deur kan gesloten zijn.

Als je bijvoorbeeld de filesize moet specificeren bij een ctor overload, dan mag deze niet negatief zijn. Hiervoor kun je een uint pakken of het argument controleren en een ArgumentException gooien. Hier zijn Exceptions niet meer dan normaal.

Eens.

[MTWZZ]

whoami schreef op donderdag 11 januari 2007 @ 14:58:
Het voorbeeld dat hier eerder aangehaald werd van die gesloten deur, is bv geen exceptie. Een deur kan gesloten zijn.

Zoals .oisyn al zei, lezen:

Je gaat een deur open maken. Hierbij heb je 2 verwachte flows:
- De deur gaat open
- De deur gaat niet open (zit op slot)
Maar stel nou dat op het moment dat jij de deur open wil doen die zelfde deur in vlammen uitbarst?
Dan krijg je dus die exceptionele flow: je gaat de brandweer bellen. Het is namelijk niet een gewone uitkomst van MaakDeurOpen()

[.oisyn]

.oisyn schreef op donderdag 11 januari 2007 @ 11:53:
Performance is natuurlijk pas een argument als je duizenden objecten aan gaat maken met verkeerde parameters. Je kunt je afvragen of je dan überhaupt wel handig bezig bent.

!!!
Je moet exceptions niet maar niet gebruiken omdat ze duur zijn. Het zijn uitzondering, dus ze mogen duur zijn. Het heeft pas invloed op je performance als er heel veel exceptions gegooid gaan worden, en als dat het geval is dan moet je eens bij jezelf te raden gaan of je ontwerp eigenlijk wel goed is.

[whoami]

Nee, maar dat wou ik ook niet zeggen. _{Als je dit als reactie op mij zegt}
Ik wil gewoon zeggen: gebruik exceptions wanneer het aangewezen is, dus, als er zich een onverwacht / exceptioneel iets voordoet. (Bv, je wil iets naar een DB wegschrijven, maar je connectie is weg oid).

[shades]

whoami schreef op donderdag 11 januari 2007 @ 17:22:
Nee, maar dat wou ik ook niet zeggen. _{Als je dit als reactie op mij zegt}
Ik wil gewoon zeggen: gebruik exceptions wanneer het aangewezen is, dus, als er zich een onverwacht / exceptioneel iets voordoet. (Bv, je wil iets naar een DB wegschrijven, maar je connectie is weg oid).

In mijn geval wordt aan de hand een een userid en nog wat parms een recordset opgehaald uit een DB (via sqlcommand). Wanneer dit userid niet gevonden kan worden krijg is een lege set terug en is het object dus null. Een exception zou ik willen gooien wanneer er geen connectie gelegd kan worden met de DB.. Dit lijkt me de juiste weg