我正在阅读一些有关Java异常处理的内容,以便能够编写更好的代码。好吧,我承认,我有罪。我使用了过多的try-catch {}块,在捕获中使用了ex.printStackTrace(),甚至没有使用适当的记录器(实际上System.outSystem.err被重定向到了PrintWriter,因此生成了日志)。但是,经过几个小时的阅读,我发现自己处在一个陌生的地方:未知的地方。如果异常被设计为传递有关异常流状态的信息,那么人们如何知道WHERE是使用该信息执行操作的适当级别?

例如,当发生数据库错误时,应该返回空值或错误代码还是引发异常?如果抛出异常,应该在哪里处理该异常?我知道,即使您无法对此进行任何记录,甚至记录异常也没有用。但是,在GUI应用程序中,这很容易杀死您的GUI(我正在使用SWT,而且我经常看到这种情况),即使是menuShown()方法(如果未处理,则ArrayIndexOutOfBounds异常也会关闭该应用程序)。该示例可能永远持续下去,但这是问题的摘要:

  • 是否过度使用try-catch()对性能有负面影响?
  • 使用特定的异常类型更好吗?如果我错过了一个怎么办
    可能发生的X种异常类型?
    坦白说,在2-3年中,我只听说过Java标准异常,并且只使用了10%。是的,有人说如果调用者不知道如何处理抛出的异常,那么他应该没有权利调用抛出方法。是对的吗?
  • 我已经阅读了AndersHejlsberg的这篇文章,说检查异常是不好的。在某些情况下,这是否应该建议建议方便地吞咽异常?
  • 一幅图片值(value)1000字;我想一些例子会很有帮助
    这里。

  • 我知道这门类(class)是永恒的​​,但实际上我很期待根据您的建议回顾一个150个类(class)的中型项目。非常感谢。

    最佳答案

    那里是异常(exception),因此Task的程序员不必自己解决问题。 (1):如果问题对他来说不是逻辑上要在任务中处理。
    从流中读取字符串的任务不是应该处理磁盘错误吗?但是,如果数据不包含字符串,则应该非常合乎逻辑。

    (2):他无法自己处理(信息不足)
    从文件和未找到的文件中读取字符串的任务可能会要求用户选择另一个文件,但是现在该任务如何才能将文件放在哪个文件夹中,文件可能是哪个扩展名。在不知道的情况下,任务如何创建GUI来重新询问。

    (3):没有逻辑(或可管理)的方式来区分不同的 yield 。
    如果任务无法读取文件,则返回null。如果文件格式错误,也返回null怎么办?这两个有什么不同?可以使用异常(exception)来区别这一点。那就是为什么它被称为Exception :-D。

    (4):有许多相似的任务需要相似的处理和编写方式,而所有任务都难以维护。
    编写用于所有访问的句柄代码可能会一团糟,因为您可能需要进行很多重复。

    
    interface DBAccess {
        public Result accessDB();
    }
    
    class DBOperation {
        static public void DoOperation(DBAccess pAccess) {
            try { return DBAccess.accessDB(); }
            catch(InvalidDBPasswordException IPE) {
                 // Do anything about invalid password
            }
            catch(DBConnectionLostException DBCLE) {
                 // Do anything about database connection lost
            }
            // Catch all possible DB problem
        }
    }
    
    ...
    
    private User[] ShowUserList_and_ReturnUsers() {
        // Find the used.
    
        // Show user list
    
        if (Users.count() == 0)
             return null;
        else return Users;
    
        // No need to handle DB connection problem here
    }
    private User[] GetUserProfile() {
        // Find the used and return
        // No need to handle DB connection problem here
    }
    ...
    
    /** An onClick event to show user list */ {
        DBOperation.DoOperation(new DBAccess() {
            public Result accessDB() {
                return ShowUserList_and_ReturnUsers();
            }
        });
    }
    /** An onClick event to show a user profile */ {
        DBOperation.DoOperation(new DBAccess() {
            public Result accessDB() {
                return GetUserProfile();
            }
        });
    }
    ... Many more DB access
    

    (5):编写所有错误检查会使任务复杂或减慢速度。
    上面的问题应该表明它如何帮助减少并发症。这是不减慢速度的方法。
    
    
    for(int i = 0; i < Users.length; i++) {
        User aUser = Users[i];
        // Do something with user
    }
    
    Replaced with
    
    try {
      for(int i = 0; ; i++) {
          User aUser = Users[i];
          // Do something with user
      }
    }
    catch(ArrayOutOfBoundException AOBE) {}
    

    如果用户数量很多,替换代码将具有更好的性能。

    当发生数据库错误时,应该返回一个空值,错误代码还是引发异常?
    答:取决于哪种错误。就像您找不到用户一样,这不是错误。但是,如果密码错误或连接断开,这些都是错误,因为尝试以常规方式处理该程序会使程序复杂化。

    (1)。使用过多的try-catch()对性能有负面影响吗?
    回答:根据“有效的Java”,就我所记得的而言,它的作用非常小(仅在循环中效果不佳)(我现在没有这本书了)。

    (2)。
    使用特定的异常类型更好吗?
    回答:特定于用户的一种更好地避免解决错误的问题。

    如果我错过了可能发生的X种异常之一,该怎么办?坦白说,我在2-3年内只听到并使用了10%的Java标准异常。
    回答:就像处理错误一样,您也可能会错过它。您只需在发现时将其添加即可。

    是的,有人说如果调用方不知道如何处理引发的异常,那么他应该没有权利调用throwing方法。是对的吗?
    回答:不,如果我不知道该怎么做,请重新抛出。

    (3)。我读过Anders Hejlsberg的这篇文章,说检查异常是不好的。在某些情况下,这是否应该建议建议方便地吞咽异常?
    回答:我认为他是在谈论“检查异常”作为编译器的功能,以确保应处理某些异常。具有异常(exception)的想法。

    (4)。一张图片值(value)1000字。.我想一些例子在这里会大有帮助。
    回答:上面的代码。

    我现在开始运行....对不起... :-p(等一下,亲爱的!)

    10-06 08:59
    查看更多