Question

如何从业务逻辑中分离出异常处理/错误处理？我在Perl中编写代码，错误/异常处理和业务逻辑使得在审阅时理解代码非常困难。

如何重构我的代码以使其更具可读性并具有错误处理功能。另请注意，我不使用try catch或类似的东西。

我们的一位高级程序员建议我们重新打开操作系统标准错误并在那里写下所有内容，我们可以通过调用者来捕获它。

编辑：这是我如何进行错误处理。我有很多Perl模块.. 所以check2.pm

package check2;
sub printData {
      print STDERR "Error Message from sub routine \n";
    }
    1;

我在我的Perl脚本check.pl

中使用它

在我的Perl脚本中

#!/usr/bin/perl
use LoadModules;
use strict;
use warnings;

load check2;

my $stderrholder;
local *SAVEERR;

# First, save existing STDERR
open SAVEERR, ">&STDERR" or print "not able to open";
close STDERR;

# Open the STDERR to a variable
open STDERR, ">", \$stderrholder or die "Failed to reopen STDERR $!\n";

#Start of processing

# Now print something to STDERR, redirected to $ stderrholder
print STDERR " Error Message from Main script \n";

check2::printData();

#End of processing

# Now close and restore STDERR to original condition.
close STDERR;
#open STDERR, ">&SAVEERR";

# Now check if there were any processing errors.
if(length($stderrholder)) {
  print "\nProcessing errors\n" ;
if(length($stderrholder)) {
  print "\nProcessing errors\n" ;
  print $stderrholder;
} else {
  print "\nNo Processing errors\n" ;
}

如果有人可以帮我指出错误，我真的很感激。

Answer 1

导致错误的代码

 sub whatever { 
    die "OH NOES" if an_error($occurred);
 }

您的主要计划：

 use Try::Tiny; # essential
 my $logger = anything_you_want;
 try {
     whatever;
 }
 catch {
     $logger->error("Error: $_");
 };

出现任何问题时抛出异常。在有意义的地方处理例外情况;通常在顶层。

有时您可以“修复”异常;示例：如果主服务器不可用，则连接到故障转移服务器。在这种情况下，处理比顶级应用程序更高级别的故障转移，但比“连接”功能更接近：

sub connect {
    die "Error connecting: ..." if ...;
}

sub make_connection {
   my $connection = try { connect($main_server) };
   $connection ||= try { connect($backup_server) };
   die "Couldn't connect to either server" unless $connection;
   return $connection;
}

然后，您将在顶级代码中处理“无法连接到任一服务器”，而不是每个连接错误。

最后，您还可以使用Error monad。这使您可以返回失败代码，但它确保在失败后不执行任何代码。（这种方法更适用于基于事件的异步代码......但是大多数Perl程序员不喜欢monad而是尝试使用异常。但这很好，但是...异常是处理错误的好方法。）< / p>

Answer 2

很好的问题，但我认为即使它使代码更复杂，也不应该从业务逻辑中删除错误处理，因为通常情况下业务逻辑需要知道错误。

我认为您可能希望重新考虑业务逻辑，以便将错误处理包含在业务逻辑中。这可能会奏效，但我认为它不可能或甚至不是一个好主意来随时分离错误处理。

我认为你的问题的答案在很大程度上取决于应用程序的类型和业务逻辑的复杂性。

Answer 3

如何使它变得非常困难？你能举出一个难以解释的例子吗？

在处理错误时，您可以在perl中生成相当可读的代码。例如，open(my $filehandle, '>', $filename) or die "Failed to open $filename"是一个可以理解的英语句子。此外，您可以使用autodie启用自动捕获常见错误。

我们的一位高级程序员建议我们重新打开操作系统标准错误并在那里写下所有内容，我们可以通过调用者来捕获它。

这比我想的更好，但不要止步于此。在while（1）循环和一个巨大的try / catch中包装整个代码不会让你做任何复杂的事情，加上它是一个巨大的代码味道。

最后：

请注意，我不使用try catch或类似的东西。

为什么不呢？

如何在Perl中将错误处理与业务逻辑分开？

3 个答案: