C# exceptions

[Verwijderd]

Beste mensen,
ik ben nieuwe in code wereld en ben met een school opdracht bezig. ik zit op volgende punt vast en kom met google niet verder

opdracht is als volg:

1 - Maak een methode om de gebruiker te vragen om een startwaarde.
Deze methode moet een exceptie geven, met een zinvolle melding, als iets
anders dan een positief getal wordt opgegeven.
methode signatuur: int VraagStartGetal() { … }

2 - Maak een methode om het volgende getal te bepalen.
Indien het opgegeven getal kleiner of gelijk 1 is dan moet een exceptie
gegeven worden (met zinvolle melding).
methode signatuur: int VolgendGetal(int waarde) { … }

3 - Maak nu de Main methode.
Gebruik hierin de beide andere methoden.
Geef als resultaat: de beginwaarde en het aantal stappen.
Vang een eventuele exceptie correct af en toon de foutmelding op het
console.

bij opgave 1 zit ik met een probleem. aangezien methode een int waarde terug geeft verwacht console dat beide paths een int waarde terug geven?!?!
kan iemand mij hier verder helpen.

alvast bedankt.

static void Main(string[] args)
{
VraagStartGetal();
wachtenOpGebruiker();


}

private static int VraagStartGetal()
{
try
{
Console.WriteLine("voer een getal in: ");
int invoerGetal = int.Parse(Console.ReadLine());
if (invoerGetal < 0)
throw new Exception("Ongeldige getal.");
Console.WriteLine("Bedankt!");
return invoerGetal;
}

catch (Exception e)
{
Console.WriteLine("Error: " + e.Message);
// int return waarde ???
}
}

private static void wachtenOpGebruiker()
{
Console.ReadKey();
}

[Verwijderd]

Waar staat dat je de exception moet catchen ipv direct throwen?

[Venxir]

Ik zou de exception lekker opvangen in main en opnieuw starten . Dan knalt hij uit je VraagStartGetal omdat daar geen try/catch is en dan gaat hij in de aanroepende functie(main) zoeken of hij het daar kan afhandelen .

[Daos]

Op zich is die try catch goed omdat int.Parse ook Exceptions kan gooien en je niet wilt dat deze door de aanroepende functie ontvangen worden. Je kan ipv Parse ook TryParse gebruiken die geen exceptions gooit of in je catch een nieuwe/duidelijkere exception gooien. Als je een exception gooit, dan hoef je niets te returnen. De melding dat niet alle paden een int returnen verdwijnt dan.

Verder zou ik klagen bij de docent over het gebruik van Nederlands in de functie-namen. Een normaal mens gebruikt hier Engels voor.

[Caelorum]

Verwijderd schreef op vrijdag 07 oktober 2016 @ 19:35:
Waar staat dat je de exception moet catchen ipv direct throwen?

Dit dus. Lees de opdracht nog even goed door en kijk bij elk punt wat je met een eventuele exceptie moet doen? Moet je deze throwen of juist catchen? Vergelijk dat dan even goed met hoe je code nu in elkaar zit en dan wordt het duidelijk wat je moet aanpassen om het te laten werken.

Daos schreef op vrijdag 07 oktober 2016 @ 20:34:
[...] Je kan ipv Parse ook TryParse gebruiken die geen exceptions gooit of in je catch een nieuwe/duidelijkere exception gooien.[...]

Dat is alleen niet de opdracht.

[...]
Verder zou ik klagen bij de docent over het gebruik van Nederlands in de functie-namen. Een normaal mens gebruikt hier Engels voor.

offtopic:
Dit is al een jarenlange discussie en niet de moeite waard hier op te brengen. Ik werk dagelijks in een voor een groot deel Nederlandstalige codebase met normale mensen. Hoewel het niet mijn voorkeur heeft zit het ons niet in de weg en wordt er goed geld mee verdient Er over klagen is dan ook zinloos en helpt de TS niet verder in zijn studie.

Verder nog even een tip. Als je je code tussen [code][/code] tags plaats krijg je mooie formatting.

[ Voor 4% gewijzigd door Caelorum op 07-10-2016 20:50 ]

[Daos]

Caelorum schreef op vrijdag 07 oktober 2016 @ 20:48:
Dat is alleen niet de opdracht.

Wat is daar niet de opdracht aan? Als je de try catch weghaalt krijg je een cryptische exception als het parsen mislukt. Dit lijkt mij niet volgens de eis "met een zinvolle melding". Dit kan je dus voorkomen met de tips die ik gegeven heb (TryParse gebruiken en zelf wat gooien of Parse blijven gebruiken met een try/catch eromheen en zelf iets gooien in de catch).

[Caelorum]

Daos schreef op vrijdag 07 oktober 2016 @ 21:00:
[...]
Wat is daar niet de opdracht aan? Als je de try catch weghaalt krijg je een cryptische exception als het parsen mislukt. Dit lijkt mij niet volgens de eis "met een zinvolle melding". Dit kan je dus voorkomen met de tips die ik gegeven heb (TryParse gebruiken en zelf wat gooien of Parse blijven gebruiken met een try/catch eromheen en zelf iets gooien in de catch).

Ohja Het is al laat he!

[kzin]

Om zo weinig mogelijk af te wijken van de code van de TS, denk een na wat er gebeurt als Console.ReadLine() geen int teruggeeft maak text. Dan zal je int.Parse() al een exceptie geven. Dat heeft Daos ook al aangegeven. Vang eerst de ReadLine() op in een string, dan weet je bij excepties tenminste wat de invoer was. (denk er om dat het ook NULL kan zijn)

[Verwijderd]

Omdat je in VraagStartGetal een try..catch hebt staan, moet je verplicht een retourwaarde opgeven (tenzij je de exception rethrowed). Als je geen try catch gebruikt, dan zal een Exception op een hoger niveau opgegooid worden. Als er dan een exception optreed, dan is er geen retourwaarde nodig.

In je Main kan je dan meerdere catches opgeven met verschillende 'soorten' Exceptions en de daarbij behorende nette melding tonen. Meerdere catches staat niet expliciet in de opdracht, maar sluit ze volgens mij ook niet uit

[ChaZy]

Ik weet niet of je er nu al wat aan hebt maar om wat meer achtergrond te krijgen over exception handling Google even op "exception throw early and catch late". Het is altijd goed om best practices te zien.