在支持 java.lang.Exception 且没有输入/输出参数的同一包装上下文中执行通用代码块的好方法?

发布于 2025-01-15 22:50:30 字数 1437 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

爱要勇敢去追 2025-01-22 22:50:30

简而言之,最佳找到的策略:

import java.util.concurrent.Callable;

// ...

  void foo() {

    execCode( () -> doBar() ) ;
    execCode( () -> 5 + 2 ) ;
    execCode( () -> { System.out.println( "test" ) ; return 0 ; }) ;
  }


  void execCode( Callable<Object> code ) {

    try {

      code.call() ;

    } catch( Exception e ) {

      // ...
    }
  }

更多详细信息:

解决方案部分在其他答案中找到及其缺点

  • (SL):使用 java.util.concurrent.Callable (上述解决方案)
    • 满足上述所有要求
    • 如果需要的话,也可以很好地处理一些返回值
  • (SF):使用java.util.Function
    • 不支持(E)
    • 尤其是(V),它更加混乱((S))并且语义上令人困惑
    • 例如 void foo() { execCode( (i) -> doBar() ) ... void execCode( Functioncode ) { ... code.apply( null ) 。 .. }
    • 另请参阅此答案
  • (SI):创建一些自定义接口(类)来完成它
    • 矛盾(S)
    • 例如接口代码{abstract void run() throws Exception; }
    • 另请参阅此答案
  • (SM):使用诸如 之类的方法引用>this::doBar
    • 特殊情况,如果代码(已经)在某些对象方法中,则可能会非常简短和优雅(S)
    • 可以使用 execCode( Callable... ) { ... }
    • 但不能使用 execCode( Runnable ... ) { ... }
      • 矛盾(E)
    • 另请参阅此答案
  • (SR):使用java.lang.Runnable
    • (E)相矛盾,因此与(S)相矛盾,因为它只允许抛出RuntimeException,但不允许抛出异常
    • 另请参阅此答案
  • (SA):使用java.lang.AutoCloseable >
    • 它符合(E)(V)(L)要求,但至少需要一些注释来解释,为什么有一个 execCode( AutoCloseable code ) { ... code.close() ; ... } 尽管代码不必对语义结束上下文执行任何操作:)
  • (SC):使用 java.util.function.Consumer< /代码>
    • 不支持(E)
    • 另请参阅此答案* (SX):使用java.lang.reflect.Method
    • 会特别矛盾(S)
    • 另请参阅此答案

  • (S.7)命令模式< /em> 解决方案
    • 是否必须兼容 Java 7(与 (8) 相矛盾)此答案使用命令模式可能是一些很好的解决方案

best found strategy in short:

import java.util.concurrent.Callable;

// ...

  void foo() {

    execCode( () -> doBar() ) ;
    execCode( () -> 5 + 2 ) ;
    execCode( () -> { System.out.println( "test" ) ; return 0 ; }) ;
  }


  void execCode( Callable<Object> code ) {

    try {

      code.call() ;

    } catch( Exception e ) {

      // ...
    }
  }

more details:

solutions partially found in other answers and their disadvantages for above:

  • (S.L): using java.util.concurrent.Callable (above solution)
    • fulfills all above requirements
    • would also nicely work with some return value, if needed
  • (S.F): using java.util.Function
    • does not support (E)
    • especially with (V) it's more clutter ((S)) and semantically confusing
    • e.g. void foo() { execCode( (i) -> doBar() ) ... void execCode( Function< Void, Void > code ) { ... code.apply( null ) ... }
    • see also this answer
  • (S.I): creating some custom interface (class) to accomplish it
    • contradicts (S)
    • e.g. interface Code { abstract void run() throws Exception; }
    • see also this answer
  • (S.M): using method references like this::doBar
    • special case which may be very short and elegant if the code is (already) in some objects method contributing to (S)
    • would work with execCode( Callable<Object> ... ) { ... }
    • but not with execCode( Runnable ... ) { ... }
      • contradicts (E)
    • see also this answer
  • (S.R): using java.lang.Runnable
    • contradicts (E) and thus (S) since it would only allow to throw RuntimeException but no checked ones
    • see also this answer
  • (S.A): using java.lang.AutoCloseable
    • it matches the (E), (V) and (L) requirements, but it needs at least some comments to explain, why there is a execCode( AutoCloseable code ) { ... code.close() ; ... } although the code does not have to do anything with a semantic closing context :)
  • (S.C): using java.util.function.Consumer
    • does not support (E)
    • see also this answer* (S.X): using java.lang.reflect.Method
    • would contradict especially (S)
    • see also this answer
  • (S.7): command pattern solution
    • if it must be Java 7- compatible (contradicting (8)) this answer with the command pattern may be some good solution
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文