try
{
psi.FileName = @"C:/Users/User/AppData/Local/Programs/Python/Python38-32/python.exe";
var PyScript = @"Load.py";
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
psi.RedirectStandardOutput = true;
psi.RedirectStandardError = true;
psi.Arguments = $"\"{PyScript}\"";
var errors = "";
var output = "";
using (var process = Process.Start(psi))
{
errors = process.StandardError.ReadToEnd();
output = process.StandardOutput.ReadToEnd();
}
richTextBox2.AppendText(errors);
richTextBox2.AppendText(output);
}
catch (Exception eU)
{
// Сообщение о ошибке
MessageBox.Show(eU.Message);
// Информаци о ошибке
MessageBox.Show(eU.ToString());
}
from datetime import datetime
import sys
import pytz
import time
j = 0
while(True):
time.sleep(0.5)
print("Next step " + str(j))
j = j + 1
if(j > 10):
break
'StandardOut has not been redirected or the process hasn't started yet.'
private void button1_Click(object sender, EventArgs e)
{
output = process.StandardOutput.ReadToEndAsync().ToString();
errors = process.StandardError.ReadToEndAsync().ToString();
richTextBox2.AppendText(errors);
richTextBox2.AppendText(output);
}
System.Threading.Tasks.Task`1[System.String]System.Threading.Tasks.Task`1[System.String]
private void button1_Click(object sender, EventArgs e)
{
output = process.StandardOutput.ReadLineAsync().Result;
errors = process.StandardError.ReadLineAsync().Result;
richTextBox2.AppendText(errors);
richTextBox2.AppendText(output);
}
private async void button1_Click(object sender, EventArgs e)
{
string output = await process.StandardOutput.ReadToEndAsync();
string errors = await process.StandardError.ReadToEndAsync();
richTextBox2.AppendText(errors);
richTextBox2.AppendText(output);
}
'The stream is currently in use by a previous operation on the stream.'
Next step 0
Next step 1
Next step 2
Next step 3
Next step 4
Next step 5
Next step 6
Next step 7
Next step 8
Next step 9
Next step 10
'The stream is currently in use by a previous operation on the stream.'Это означает, что Вы пытаетесь прочитать стрим когда кто-то его уже читает. Этот кто-то - прошлое нажатие кнопки. Стрим нельзя прочитать дважды.
private async void button1_Click(object sender, EventArgs e)
{
button1.Enabled = false; // честно не помню работу с GUI, проверьте как правильно свойство называется
using (var process = Process.Start(psi))
{
bool hasOutput, hasErrors;
do
{
string? output = await process.StandardOutput.ReadLineAsync();
string? errors = await process.StandardError.ReadLineAsync();
hasOutput = !(output is null);
hasErrors = !(errors is null);
if (hasOutput) richTextBox2.AppendText(output);
if (hasErrors) richTextBox2.AppendText(errors);
}
while (hasOutput || hasErrors);
}
}
Feature 'nullable reference types' is not available in C# 7.3. Please use language version 8.0 or greater.
private async void button1_Click(object sender, EventArgs e)
{
try
{
bool hasOutput, hasErrors;
string output = await process.StandardOutput.ReadLineAsync();
string errors = await process.StandardError.ReadLineAsync();
hasOutput = !(output is null);
hasErrors = !(errors is null);
if (hasOutput) richTextBox2.AppendText(output);
if (hasErrors) richTextBox2.AppendText(errors);
}
catch (Exception eU)
{
// Сообщение о ошибке
MessageBox.Show(eU.Message);
// Информаци о ошибке
MessageBox.Show(eU.ToString());
}
}
Feature 'nullable reference types' is not available in C# 7.3. Please use language version 8.0 or greater.Ваша версия шарпа не умеет работать с типами вида string? - это подсказка тайпчекеру, что тут может null быть, пусть требует проверки. Если убрать знак вопроса, кардинально ничего не поменяется
private async void button1_Click(object sender, EventArgs e)
{
try
{
using (var process = Process.Start(psi))
{
bool hasOutput, hasErrors;
do
{
string output = await process.StandardOutput.ReadLineAsync();
string errors = await process.StandardError.ReadLineAsync();
hasOutput = !(output is null);
hasErrors = !(errors is null);
if (hasOutput) richTextBox2.AppendText(output);
if (hasErrors) richTextBox2.AppendText(errors);
}
while (hasOutput || hasErrors);
}
}
catch (Exception eU)
{
// Сообщение о ошибке
MessageBox.Show(eU.Message);
// Информаци о ошибке
MessageBox.Show(eU.ToString());
}
}
"P.S. я еще обычно рекомендую избавляться от try-catch, ибо это путь в сторону неподдерживаемого хаоса..."
#nullable enable
using System;
using System.Diagnostics;
using System.Windows.Forms;
namespace WindowsFormsApp
{
public partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
}
private async void OnButtonClick(object sender, EventArgs e)
{
button.Enabled = false;
try
{
using var process = Process.Start(psi);
bool hasOutput, hasErrors;
do
{
string? output = await process.StandardOutput.ReadLineAsync();
string? errors = await process.StandardError.ReadLineAsync();
hasOutput = output != null;
hasErrors = errors != null;
if (hasOutput) richTextBox.AppendText(output);
if (hasErrors) richTextBox.AppendText(errors);
} while (hasOutput || hasErrors);
}
catch (Exception ex)
{
// Логируем и/или выводим на экран информацию.
}
finally
{
button.Enabled = true;
}
}
}
}
<LangVersion>latest</LangVersion>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<LangVersion>latest</LangVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<LangVersion>latest</LangVersion>
</PropertyGroup>
output != null
v != null
Не нужно от них избавляться. Если это нажатие на кнопку, там ему самое место, просто нужно или залогировать информацию об ошибке, или вывести информацию на экран (или всё вместе). Если бы он в классе с алгоритмом подавлял ошибки, то да, это было бы не то что неподдерживающийся хаос, это просто был бы нерабочий код, который нельзя так писать. Проще говоря, если не будет трай кэтча в методе нажатия на кнопку, то приложение будет просто крашиться. Мы же можем приложение не крашить, а просто завершить выполнение работы не получив результат. В таком случае, имея логи, можно разобраться в проблеме. Бывают ошибки, не связанные с алгоритмом, например, антивирус заблокировал файл, не удалось его открыть и прочитать. У меня такое было.Если произошло исключение (исключительная ситуация) - программа должна была падать, ибо это косяк программиста и его надо ловить как можно раньше. Если файл не читается - это не исключение, а ошибка, ее не надо кидать через throw, ее нужно возвращать через return и обрабатывать, ибо это штатная ситуация, ожидаемый результат вызова. Вездесущие try-catch - рассадник багов.
!(value is null)
value != null
чем операция is более надёжна? Чем проверка
!(value is null)
надёжнее такой проверки?
value != null
про исключение вообще забавно. Особенно про нечитаемый файл и возврат с помощью return. И что нужно по вашему вернуть через return, если файл не читается? Слово Error :)? Нужно бросать исключение, а если быть точным, то оно будет брошено методом класса фреймворка, если файл не удастся открыть. Какие могут быть баги, если try catch на уровне метода нажатия на кнопку и пользователь знает об ошибке? В данной ситуации try catch нужно использовать, а не крашить приложение.
мысль интересная, но "если да кабы", в данном случае точно известно, что нет там никаких переопределённых операторов, это обычная строка.Я бы не был так уверен работая с completeness type system. Ну и даже если сегодня там строка, от которой нельзя наследоваться, никто не гарантирует, что завтра эту строку не завернут в декоратор, и у него не будет перегрузки операторов. И тайпчекер ничего не скажет, что проверка на null вдруг стала некорректной. И даже если здесь всегда будет строка, в других местах может быть не строка, и у Вас будет 100500 разных вариантов сделать одно и то же, либо будут ошибки.
Зачем выдумывать какую-то надёжность и проблему, которой нет и быть не может?Если бы проблемы не было, то с развитием языка не появлялись бы способы для ее решения. Проблема огромна, большинство ПО пестрит багами, и большинство из них существуют из-за таких вот "я не вижу проблем, я не хочу развиваться, я застрял в 90х и мне норм, пишу как умею".
Если проверка на null кинет эксепшен, то это нужно исправить тому, кто пишет код, а не "надёжной" проверкой скрывать проблему.То есть по Вашему лучше переложить ответственность, заодно наложив искусственные неявные ограничения, вместо того чтоб решить проблему на корню? Использование более надежного подхода как раз таки не скрывает проблему, а решает ее.
И причём здесь вообще библиотека и функциональный подход?А причем тут функциональный подход? Или увидели монады и все, "а-а-а, ФП, сложна, лучше пойду дальше быдлокодить"? Так вот, монады это не про ФП, монады это про гарантии, что с данными будут работать корректно. И да, ошибки - это тоже данные, поэтому их нужно возвращать как результат, а не бросать вместе с исключительными ситуациями, и монада Either (или аналоги) идеально для этого подходит, так как гарантирует, что вызывающая сторона не получит свои данные пока не обработает ошибку. Механизм throw-try-catch ничего не гарантирует, а на практике он приводит к скрытым багам из-за нарушенного потока данных.
"я не вижу проблем, я не хочу развиваться, я застрял в 90х и мне норм, пишу как умею".
А причем тут функциональный подход? Или увидели монады и все, "а-а-а, ФП, сложна, лучше пойду дальше быдлокодить"?