Hallo, ich nutze den PAPDesigner. Wie würdet ihr eine try-catch-Anweisung darstellen?
bloß nicht alle aufeinmal
Gast
#6396465
Antonow B. schrieb: > bloß nicht alle aufeinmal Wer nach einer Stunde bereits so nett ist, erhält eher keine Antworten. Ich persönlich finde so ein Verhalten ja ein wenig dreist.
Versuchs mal mit Try & error!
Gast
#6396468
Antonow B. schrieb: > bloß nicht alle aufeinmal Exoten verwenden, nicht bedienen koennen, Hilfe im Forum suchen und nach 1 Stunde pampig herumschreien. Gute Besserung, leo
Gast
#6396472
Schreib dein Programm doch einfach in Java. Da gibt es try-catch, und in den Hunderten Büchern die es dazu gibt steht auch wie das geht.
Bei solch einer Anspruchshaltung gäbe es auch von mir keine zielführende Antwort.
Schade das so ein Depp, der offensichtlich nichts allein rafft, den Namen "Antonow" im Nick tragen darf!
Gast
#6396549
Thomas W. schrieb: > Schade das so ein Depp, der offensichtlich nichts allein rafft, den > Namen "Antonow" im Nick tragen darf! Antonow ist doch kein Name, das ist ein Sammelbegriff. So wie im deutschen Sprachraum Müller oder Schmidt.
also: mein Problem steht daraus, das der PAPDesigner vorgibt, dass es sowohl für einen Vorgang als auch für ein Unterprogramm nur einen logischen Ausgang gibt. Macht ja auch Sinn. Bis auf den Augenblick, wenn man mittels dieser Symbole neben dem try-Block(viel anderes kommt ja nicht in Frage) die catch-Klausel abdecken möchte
Gast
#6396583
Antonow B. schrieb: > also: mein Problem steht daraus, das der PAPDesigner vorgibt, dass es > sowohl für einen Vorgang als auch für ein Unterprogramm nur einen > logischen Ausgang gibt. Macht ja auch Sinn. Bis auf den Augenblick, wenn > man mittels dieser Symbole neben dem try-Block(viel anderes kommt ja > nicht in Frage) die catch-Klausel abdecken möchte Wenn man logisch denken könnte, würde man daraus unweigerlich den Schluß ziehen, dass ein try-catch-Konstrukt wohl weder ein "Vorgang" noch ein Unterprogramm sein kann... Wenn man logisch denken könnte, wie gesagt...
c-hater schrieb: > wohl weder ein "Vorgang" noch ein > Unterprogramm sein kann... ist mir klar. du kennst wohl PAPDesigner nicht. Da gibt es keine große Auswahl..
Gast
#6396591
Antonow B. schrieb: > ist mir klar. du kennst wohl PAPDesigner nicht. Da gibt es keine große > Auswahl.. Genug, um darzustellen, was in einem try-catch-Block passiert.
bisschen konkreter bitte
Gast
#6396597
Antonow B. schrieb: > bisschen konkreter bitte Mach' deine Hausaufgaben alleine!
c-hater schrieb: > bisschen konkreter bitte > > Mach' deine Hausaufgaben alleine! so ein schwachsinn. hast nur scheiße von dir gegeben. bist nicht der wahre c-hater. Aber ok. Konsequent bist du auch nicht, sonst hättest du dich ja garnicht auf eine Antwort eingelassen. Stattdessen druckst du rum.
Man muss sich nur den dämlichen Exception-Stack wegdenken und annehmen, dass jede Funktion neben dem eigentlichen Rückgabewert noch einen Fehler zurückgeben kann. Wer mit "multiple return values" gedanklich ein Problem hat, weil das die Sprache seiner Wahl nicht unterstützt, stelle sich einfach vor, dass der eigentliche Rückgabewert nicht direkt zurückgegeben wird, sondern in einem Struct (oder meinetwegen in einem Objekt) verpackt ist, welcher neben dem eigentlichen Rückgabewert noch eine Fehlervariable beinhaltet. Dann prüft man mit einem simplen "if" die Fehlervariable (im Zweifelsfall innerhalb des zurückgegebenen structs) und führt entweder eine Fehlerbehandlung durch (z.B. durch weiterreichen des Fehlers an den Caller) oder macht eben einfach nichts, weil es keinen Fehler gab und verwendet das eigentliche Ergebnis im weiteren Programm. Sowohl Go, als auch Rust machen das so (mit "multiple return values), also im Zweifel einfach mal nach "error handling in go" suchen, dann wird es klarer.
vielen Dank für deinen Beitrag. das mit der if-Anweisung hatte ich mir überlegt, aber aus verschiedenen Gründen verworfen. Hätte gerne eins zu eins die try-catch-Anweisung
Antonow B. schrieb: > vielen Dank für deinen Beitrag. das mit der if-Anweisung hatte ich > mir > überlegt, aber aus verschiedenen Gründen verworfen. Hätte gerne eins zu > eins die try-catch-Anweisung vllt bin ich auch einfach nur ein stückweit dickköpfig. Könnte mir notfalls ein PAP in Word oder Powerpoint zeichnen. Nur: ich habe einige andere PAPs mit dem Designer erstellt, möchte kein inhomogenes Gesamtbild schaffen
Antonow B. schrieb: > vielen Dank für deinen Beitrag. das mit der if-Anweisung hatte ich mir > überlegt, aber aus verschiedenen Gründen verworfen. Hätte gerne eins zu > eins die try-catch-Anweisung Naja, try-catch gibt es halt nicht "eins zu eins", weil try-catch eben einen Haufen Zeug hinter den Kulissen macht und PAP eben nur Zuweisung, Verzweigung und Wiederholung kennt, was eben grundsätzlich ausreichend ist. Das ein "richtiges" try-catch (wie z.B. in C++) so "weit entfernt von der eigentlichen Programmlogik" ist, ist unter anderem der Grund warum es das so in moderneren Sprachen gar nicht mehr gibt (siehe Go oder Rust).
Gast
#6396890
> das so in moderneren Sprachen gar nicht mehr gibt
Das ist auch ausdruecklich zu begruessen.
Wer einmal das 50 GB grosse Logfile einer von Fickelbrogrammierern
geschriebene Applikation gesehen hat, wird wissen warum.
Die 50 GB kamen auch nicht im Betrieb zustande, sondern
waren nur das, was nach dem Start bis die Applikation
Online war, geloggt wurde.
Try und Catch hatten da einen wesentlichen Anteil...
Gast
#6396924
Mit den Programmablaufplänen soll Einsteigern auf einer abstrakten Ebene die rudimentären Konzepte des Programmierens nahegebracht werden (so wie man Erstklässler mit Gummibären ans Rechnen führen kann). Die Teile haben gar nicht den Anspruch, jedes Konstrukt einer konkreten Sprache abbilden zu können (mit Gummibären kommt man in der Mathematik auch nicht weit). Falls die Einsteiger irgendwann mal zu Exceptions kommen, haben sie die Programmablaufpläne schon längst in die Tonne getreten.
Gast
#6396948
foobar schrieb: > Die Teile > haben gar nicht den Anspruch, jedes Konstrukt einer konkreten Sprache > abbilden zu können Das ist zwar korrekt, aber irgendwie auch falsch. Im Prinzip brauchen sie nur zwei "Elemente" bereitstellen, am ALLES abbilden zu können, was sich als logisches Programm schreiben läßt. Die zwei Elemente sind: Zuweisung und bedingte Verzweigung. Was darüber hinaus angeboten wird, sind schon Zusammenfassungen dieser beiden Grundelemente zwecks besserer Übersicht. Im Prinzip genau wie der Syntaxbombast der Hochsprachen. Auch die fassen die Grundelemente zu (hoffentlich) besser lesbaren Strukturen zusammen. Nicht immer gelingt das...
foobar schrieb: > Mit den Programmablaufplänen soll Einsteigern auf einer abstrakten Ebene > die rudimentären Konzepte des Programmierens nahegebracht werden Wenn ich mir etwa Doku von integrierten Bootloadern anschaue bin ich immer froh, wenn es dazu einen Programmablaufplan gibt. Der ist "programmiersprachenneutral" und jeder kann den verstehen, nicht nur Anfänger. foobar schrieb: > Falls die Einsteiger irgendwann mal zu Exceptions kommen, haben sie die > Programmablaufpläne schon längst in die Tonne getreten. Hoffentlich nicht. Exceptions finde ich im Mikrocontroller-Bereich fast genauso unangebracht wie Java.
Hallo, hat jemand noch einen Ansatz, z.B. ein anderes Tool, mit dem ich die try-catch Anweisung als PAP darstellen kann?
Antonow B. schrieb: > hat jemand noch einen Ansatz, z.B. ein anderes Tool, mit dem ich die > try-catch Anweisung als PAP darstellen kann? Nochmal im Klartext: In einem Flowchart (PAP) gibt es wie von c-hater schon erwähnt nur zwei Dinge: 1. Zuweisung 2. Bedingte Verzweigung Alles andere baut auf diesen beiden Blöcken auf, eben auch so etwas wie "try-catch" oder meinetwegen "try-catch-finally". Da kannst du noch so lange nach einem Tool suchen. Da du scheinbar nicht kreativ genug bist um dir das selber auszumalen hier der erstbeste Suchtreffer für "try catch flowchart": https://www.javascripttutorial.net/javascript-try-catch/
Antonow B. schrieb: > hat jemand noch einen Ansatz, z.B. ein anderes Tool, mit dem ich die > try-catch Anweisung als PAP darstellen kann? Try/Catch/Finally-Konstrukte lassen sich in einem PAP nicht vernünftig darstellen, weil es dafür keine passenden Symbole gibt. Eine Darstellung mit den gegebenen Symbolen (Terminator, Operation, Unterprogramm, Verzweigung, Pfeil, usw.) ist zwar prinzipiell möglich, führt aber schnell zu einem unübersichtlichen Gewirr, insbesondere dann, wenn - der Try-Block mehr als eine Operation enthält, - es mehr als einen Catch-Block gibt, - es einen Finally-Block gibt und/oder - nur ein Teil der Exceptions gecatcht werden. Ich wüsste auch nicht, welche zusätzlichen Symbole eingeführt werden müssten, um dieses Manko zu beheben. Hast du vielleicht eine Idee dazu? Wenn ja, kannst du ja ein bestehendes Tool wie Dia oder Visio um diese neuen Symbole erweitern. PAPs sind eben sehr viel älter als imperative Programmiersprachen, die die Ausnahmebehandlung mittels Try und Catch erlauben. Ein adäquateres Mittel zur Beschreibung solcher Konstrukte ist Pseudocode. Da Pseudocode als halbformale Beschreibungsform sehr flexibel ist, hat er PAPs, Struktogramme und dergleichen weitgehend verdrängt. Zudem ist eine Beschreibung in Pseudocode viel kompakter, so dass damit auch komplexere Algorithmen noch halbwegs übersichtlich dargestellt werden können.
Christopher J. schrieb: > lles andere baut auf diesen beiden Blöcken auf, eben auch so etwas > wie "try-catch" oder meinetwegen "try-catch-finally". Da kannst du noch > so lange nach einem Tool suchen. > > Da du scheinbar nicht kreativ genug bist um dir das selber auszumalen > hier der erstbeste Suchtreffer für "try catch flowchart": > https://www.javascripttutorial.net/javascript-try-catch/ nur das dass nicht ein PAP mit dem tr ycatch oist, sondern über. Der Unterschied: wie kann ich try, was da als ein Block dargestellt ist, detaillierte darstellen. Zumal das der Lösung mit der if-Abfrage entspricht
Christopher J. schrieb: > Da du scheinbar nicht kreativ genug bist um dir das selber auszumalen > hier der erstbeste Suchtreffer für "try catch flowchart": > https://www.javascripttutorial.net/javascript-try-catch/ Das Problem ist, dass es sich dabei um ein Diagramm handelt, das nur dazu dient, das Exception-Handling selbst zu erklären. Aber ein Programm damit darzustellen, das einfach Exceptions benutzt, dürfte damit in den meisten Fällen nicht sinnvoll möglicht sein. Die Aktion "Execute try block" wird z.B. ggf. nur teilweise ausgeführt, eben bis zu dem Punkt, wo eine Exception auftritt. Das wird in diesem Diagramm durch den nachfolgenden Teil "Ignore the rest of try block" dargestellt. Abgesehen davon, dass das teilweise nicht-Ausführen einer vorangegangenen Aktion selbst gar keine richtige Aktion ist, kann "the rest" variieren, je nachdem, wo genau die Exception auftritt.
Rolf M. schrieb: > Das Problem ist, dass es sich dabei um ein Diagramm handelt, das nur > dazu dient, das Exception-Handling selbst zu erklären. Aber ein Programm > damit darzustellen, das einfach Exceptions benutzt, dürfte damit in den > meisten Fällen nicht sinnvoll möglicht sein. genau meine Worte
gibt es für Pseudocode einen Designer? oder würdet ihr soetwas in word erstellen?
der nachteil an word ist eben, dass man eine automatische Einrückung usw hat
Beitrag #6402152 wurde von einem Moderator gelöscht.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
ich habe mich mal versucht. Würdet ihr das als Pseudocode bezeichnen? Die Funktionen wie viOpen() usw habe ich separat erklärt.
Antonow B. schrieb: > Modellnummer aus Variable extrahieren ist soetwas in Pseudocode in Ordnung? Arbeite zum ersten Mal damit
ich führe Monologe. Ist das eine Bestrafung, kollektiv ausgeführt?
Gast
#6402903
PAP? Wozu brauchst du das überhaupt? Das stinkt nach 70er Jahre-Daten-Verarbeitung und Lochkarten.
Miethai schrieb: > PAP? Wozu brauchst du das überhaupt? Das stinkt nach 70er > Jahre-Daten-Verarbeitung und Lochkarten. will pseudocode nehmen. drei beiträge drüber
Gast
#6402936
Ausnahmen dokumentiere ich fast immer in Text-Form außerhalb des PAP.
Stefan ⛄ F. schrieb: > Ausnahmen dokumentiere ich fast immer in Text-Form außerhalb des PAP. macht Sinn. ich bin aber auf Pseudocode umgesattelt. Antonow B. schrieb: > ich habe mich mal versucht. Würdet ihr das als Pseudocode bezeichnen? > Die Funktionen wie viOpen() usw habe ich separat erklärt. was meint ihr?
Antonow B. schrieb: > Modellnummer aus Variable extrahieren insbesondere diese Zeile.
Gast
#6402949
In meinen PAP findet man mit Absicht nicht jedes einzelne if Statement und jede Loop wieder - schon gar nicht alle Variablen. Sie Da gibt es eher Symbole mit Labels wie "Send notification with async repeat", oder: "Try to store the image until success or timeout". Solche Diagramme sind nett, um Geschäftslogik in ihren einfachen geradeaus-Fällen darzustellen. Also eher für den groben Überblick. Wer aber alle Details sehen will, soll sich den Quelltext anschauen oder die Anforderungen lesen. Der Quelltext weicht in der Praxis sowieso oft genug von den zuvor gezeichneten Diagrammen ab, nachdem man alle Nachforderungen, Sonderlocken und Designlücken (die erst beim Entwickeln/Testen auffallen) implementiert hat. Komplette Programme detailliert als Diagramm zu beschreiben, ist meiner Meinung nach eine Schnapsidee. Was ich von UML-zu-Code-Generatoren halte, kann man daraus ableiten.
und was ist mit Pseudocode?
Gast
#6402975
Antonow B. schrieb: > und was ist mit Pseudocode? Durchaus beliebt, allerdings hat da jede Firma oder gar jede Person ihren eigenen Stil. Ich habe Bedenken, solche Dokumente nach Außen zu geben.
Stefan ⛄ F. schrieb: > Durchaus beliebt, allerdings hat da jede Firma oder gar jede Person > ihren eigenen Stil. Ich habe Bedenken, solche Dokumente nach Außen zu > geben. ich meinte meine konkrete Umsetzung
Antonow B. schrieb: > Variable = GetData() > Modellnummer aus Variable extrahieren > Falls ModellnummerVariable != ModellnummerGerät ob das in der Mitte sinnig ist
Gast
#6402984
Antonow B. schrieb: > was ist mit Pseudocode? > ich meinte meine konkrete Umsetzung Sie setzt voraus, dass man sich mit Exceptions in der jeweiligen Variante auskennt. Ich kenne keinen Anwender, keinen Betriebler und keinen Projektmanager, der damit etwas anfangen könnte. Das ist auch unklar: > Variable = GetData() Da würde ich schrieben: > set variable = getData Da wo ich derzeit arbeite, dokumentiert man den Code nach dem Programmieren (also zusätzlich zu den Anforderungsdokumenten) etwa so:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
Das ist für Techniker OK, kann man aber so nicht außer Haus geben.
Stefan ⛄ F. schrieb: > Da würde ich schrieben: >> set variable = getData woran kann man dann erkennen, dass es sich bei getData um einen Funktionsaufruf handelt?
Gast
#6402995
Antonow B. schrieb: > Stefan ⛄ F. schrieb: >> Da würde ich schrieben: >>> set variable = getData > > woran kann man dann erkennen, dass es sich bei getData um einen > Funktionsaufruf handelt? Weil es ein Link zum entsprechenden Dokument ist. Außerdem ergibt sich das aus dem Namen. Da hat natürlich jede Firma ihre eigenen Vorgaben. Aber es sollte schon klar erkennbar sein. Die Variable würde man ja auch nicth "variable" nennen. Ein relaes Beispiel: * set totalAmount = computTotalAmount of the current order Wobei computTotalAmount halt ein Link auf die Beschreibung der Funktion wäre. Ich schlage vor, diesen Gedanken hier abzuschließen, um zurück zur Frage des TO (PAP) zu kommen.
das mit Link halte ich aber nicht für intuitiv
Finde ich auch nicht so schön. Das sollte sich ohne Link selbst erklären können. Und wenn man es ausdruckt, wird's mit dem Link auch schwierig :)
Rolf M. schrieb: > Finde ich auch nicht so schön. Das sollte sich ohne Link selbst erklären > können. Und wenn man es ausdruckt, wird's mit dem Link auch schwierig :) was sagst du denn zur Umsetzung meines Pseudocodes?
Antonow B. schrieb: > was sagst du denn zur Umsetzung meines Pseudocodes? Ich finde, er ist zu wenig abstrahiert. Wenn du den echten Quellcode hinschreiben würdest, wäre der nicht so viel anders. Was gewinnst du da durch den Pseudocode? Zum Beispiel bei
1 | |
vermute ich mal, dass der einzige Unterschied ist, dass im Quellcode halt "if" statt "falls" und ein zusätzliches Klammernpaar steht.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
was ist damit? ist eine andere methode
Rolf M. schrieb: > Ich finde, er ist zu wenig abstrahiert. ja hast Recht, überarbeite ich Antonow B. schrieb: > Fehlernummer aus VariableNachricht extrahieren hier muss VariableAbfrage stehen
Stefan ⛄ F. schrieb: > Komplette Programme detailliert als Diagramm zu beschreiben, ist meiner > Meinung nach eine Schnapsidee. So ist es. Man zerlegt ein Projekt in mehrere sinnvolle Teilaufgaben und legt dafür je einen PAP an. Z.B. gibt es haufenweise Ursachen, warum das Öffnen einer Datei fehlschlagen kann (keine Zugriffsrechte, keine Schreibrechte, ungültige Zeichen im Namen, ungültiges Verzeichnis, Datei existiert bereits usw.). Dann mancht man einen PAP nur für das Öffnen, die Fehlererkennung und Behandlung. Und diesen PAP ruft man dann im übergeordneten PAP auf, mit nur 2 Ergebnissen, pass oder fail.
Gast
#6403855
Antonow B. schrieb: > das mit Link halte ich aber nicht für intuitiv Wie gesagt, jede Firma findet ihren eigenen optimalen Weg. Ich habe mir das nicht ausgedacht, sondern alle Mitarbeiter der Firma gemeinsam. Jeder findet irgend etwa gut und schlecht, so dass man am Ende einen Kompromiss wählt, mit dem alle klar kommen.
Antonow B. schrieb: > Wie würdet ihr eine try-catch-Anweisung > darstellen? Antonow B. schrieb: > bloß nicht alle aufeinmal Wenn man einfach nach "Fehlerbehandlung" fragen würde, ginge es schneller. Dann muß nicht jeder erstmal Google bemühen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.