Это хорошая идея, чтобы обернуть возвращаемое значение функций в классе. Это обеспечивает простоту кодирования, и вы можете избежать попыток... поймать, что я берусь делать что-то подобное.
public class ResultWrapper
{
public bool Success{get;set;}
public Exception ErrorMessage{get;set;}
public object Result{get;set;} //not object essentially(any type)
public Result()
{
Success=false;
ErrorMessage="";
Result=null;
}
}
public ResultWrapper DoSomething(parameters....)
{
var result=new ResultWrapper()
try
{
}
catch(Exception ex)
{
result.Error=ex;
}
return result;
}
и затем называя его
static void main()
{
var result=DoSomething(parameters...);
if(result.Success)
{
//Carry on with result.Result;
}
else
{
//Log the exception or whatever... result.Error
}
}
РЕДАКТИРОВАТЬ:
учти это
static void main()
{
var result=Login(); //throws an exception
if(result.Success)
{
//retrive the result
//carry on
result=PostSomeStuff(parameter);
if(result.Success)
{
}
else
{
Console.WriteLine("Unable to Post the data.\r\nError: {0}",result.Error.Message);
}
}
else
{
Console.WriteLine("Unable to login.\r\nError: {0}",result.Error.Message);
}
}
это не проще, чем обернуть try..catch за пределами каждой функции???
static void main()
{
try
{
var result=Login();
var result1=result=PostSomeStuff(parameter);
// a lot of functions doing seprate things.
}
catch(Exception ex)
{
//what to do...?
}
}
Нет, это анти-шаблон. Если есть какое-либо исключение, которое вы не знаете, как обращаться, пусть оно распространяется. Возвращение объектов исключений в возвращаемое значение является очень плохой идеей, когда язык поддерживает исключения.
Если метод успешный, он должен вернуть значение напрямую; если он терпит неудачу, он должен выбросить исключение. (Предостережение: некоторые методы могут возвращать bool
указывающие на успех или неудачу, и сохранять результат в параметре out
. Например, int.TryParse()
, Dictionary<TKey, TValue>.TryGetValue()
и т.д. Поскольку исключения могут быть дорогими, некоторые операции могут быть лучше подходят для простого возврата флага, указывающего на отказ, если ожидается, что отказ будет частым, но это должно быть редким явлением.)
TryXyz
работает очень хорошо, особенно при разборе. Посмотрев ваше редактирование - я думаю, что возможность получить более подробную информацию о сбое разбора полезна ... отсюда инкапсулированный ParseResult<T>
Noda Time ParseResult<T>
. Они откладывают выдачу исключения, но вы все равно можете сделать это, когда захотите.)
Обычно нет. Могут быть конкретные случаи, когда это хорошая идея, но я бы не рекомендовал ее по умолчанию.
Это сделает невозможным разрешить исключение "пузыриться" до тех пор, пока оно не попадет в хорошее место для его обработки. Это затруднит понимание кода.
Это ужасно. Подумайте, сколько слов будет добавлено в ваш код, чтобы проверить, было ли исключено исключение.
Также подумайте об этом так: если бы это была отличная идея, тогда сама.NET Framework сделала бы это. Вы когда-нибудь видели этот шаблон в.NET? У меня нет.
Вы почти всегда должны соответствовать семантике того, что использует фреймворк, в противном случае вы окажетесь в странном mish-mash. Вскоре у вас есть 10 конкурирующих "стандартов" кодирования.
string
илиint
- мы не можем ответить без дополнительного контекста ...