waar exception gooien?
Ola peepz,
Puur uit nieuwsgierigheid... waar in een functie gooi jij je exception?
Vroeger deed ik dit:
Ik koos voor deze aanpak omdat een "positief" if-statement sneller is dan een "negatief" if-statement. Ik deed het dus voor performance.
Tegenwoordig gebruik ik echter een "negatief" if-statement, en return ik de waarde pas aan het eind van de functie. Dan krijgen we dus dit:
Voor mijn gevoel is dit een logischere, duidelijkere opbouw van de functie.
Toch zag ik eerder deze week iemand op het forum de eerste versie gebruiken, en dus vroeg ik me af welke versie jullie gebruiken. De eerste of de laatste?
Puur uit nieuwsgierigheid... waar in een functie gooi jij je exception?
Vroeger deed ik dit:
Code (php)
Ik koos voor deze aanpak omdat een "positief" if-statement sneller is dan een "negatief" if-statement. Ik deed het dus voor performance.
Tegenwoordig gebruik ik echter een "negatief" if-statement, en return ik de waarde pas aan het eind van de functie. Dan krijgen we dus dit:
Code (php)
Voor mijn gevoel is dit een logischere, duidelijkere opbouw van de functie.
Toch zag ik eerder deze week iemand op het forum de eerste versie gebruiken, en dus vroeg ik me af welke versie jullie gebruiken. De eerste of de laatste?
Gewijzigd op 08/05/2014 15:17:40 door Ozzie PHP
Ik doe het altijd met try catch.
Euh... dat is op dit voorbeeld toch niet van toepassing :-s
Dan had je het topic niet "waar foutafvanging" moeten noemen. Je wilt nu namelijk weten waar je de fout zou moeten gooien.
Precondities heb ik het liefst bovenaan. En op zo'n manier dat daar ook de foutmelding staat die bij de preconditie hoort. In dat geval dus bovenaan.
Postcondities zoals "deze methode mag nooit null returnen" komen dan waarschijnlijk wel weer onderaan.
Doe wat het meest leesbaar is. En aangezien smaken verschillen mag je zelf bepalen wat dat is. Zolang je maar argumenten kunt verzinnen en verdedigen.
Oh, en zoals bijna altijd: doe dit op een case by case basis.
Precondities heb ik het liefst bovenaan. En op zo'n manier dat daar ook de foutmelding staat die bij de preconditie hoort. In dat geval dus bovenaan.
Postcondities zoals "deze methode mag nooit null returnen" komen dan waarschijnlijk wel weer onderaan.
Doe wat het meest leesbaar is. En aangezien smaken verschillen mag je zelf bepalen wat dat is. Zolang je maar argumenten kunt verzinnen en verdedigen.
Oh, en zoals bijna altijd: doe dit op een case by case basis.
Gewijzigd op 08/05/2014 15:16:41 door Dos Moonen
>> Dan had je het topic niet "waar foutafvanging" moeten noemen. Je wilt nu namelijk weten waar je de fout zou moeten gooien.
Fixed :)
>> Postcondities zoals "deze methode mag nooit null returnen" komen dan waarschijnlijk wel weer onderaan.
Hoe bedoel je dit? Wat versta je onder een "postconditie"?
Fixed :)
>> Postcondities zoals "deze methode mag nooit null returnen" komen dan waarschijnlijk wel weer onderaan.
Hoe bedoel je dit? Wat versta je onder een "postconditie"?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
package me.darsstar
import static java.util.Objects.requireNonNull;
...
public SomeObject someMethod(String miauw, int offset, int length) {
requireNonNull(miauw, "Violation of non-null contract for argument miauw");
if (offset < 0 || offset >= miauw.length()) {
throw new IllegalArgumentEception("Invalid offset");
}
if (length < 0 || length >= miauw.length() - offset) {
throw new IllegalArgumentEception("Invalid length");
}
SomeObject value;
...
value = injectedObject.someOtherMethod();
...
// dit hier
return requireNonNull(value, "Preventing violation of non-null contract for the return value");
}
import static java.util.Objects.requireNonNull;
...
public SomeObject someMethod(String miauw, int offset, int length) {
requireNonNull(miauw, "Violation of non-null contract for argument miauw");
if (offset < 0 || offset >= miauw.length()) {
throw new IllegalArgumentEception("Invalid offset");
}
if (length < 0 || length >= miauw.length() - offset) {
throw new IllegalArgumentEception("Invalid length");
}
SomeObject value;
...
value = injectedObject.someOtherMethod();
...
// dit hier
return requireNonNull(value, "Preventing violation of non-null contract for the return value");
}
Ah oke... ik moet even goed kijken. Is dit javascript?
Maar je doet dus een controle in de return. Ik zou dan zelf voordat ik return kijken of ie niet null is.
Maar je doet dus een controle in de return. Ik zou dan zelf voordat ik return kijken of ie niet null is.
Het is Java.
Dit doet het zelfde.
Post condities zijn condities die waar moeten zijn aan het eind van de methode.
Objects.requireNonNull(Object, String) source code
Dit doet het zelfde.
Code (php)
1
2
3
4
5
2
3
4
5
// dit hier
requireNonNull(value, "Preventing violation of non-null contract for the return value");
return value;
}
requireNonNull(value, "Preventing violation of non-null contract for the return value");
return value;
}
Post condities zijn condities die waar moeten zijn aan het eind van de methode.
Objects.requireNonNull(Object, String) source code
Ah oke... als ik het goed begrijp is dat dus hetzelfde als dit?
Zo bedoel je?
Zo bedoel je?
Zoals hierboven, gebruik ik..
Gewijzigd op 08/05/2014 16:25:59 door - Pepijn -




