tomcat启动设备未就绪_安全启动异常就绪协程

最新推荐文章于 2022-10-14 18:29:20 发布

weixin_26727575

最新推荐文章于 2022-10-14 18:29:20 发布

阅读量620

点赞数

文章标签： java tomcat 物联网安全 linux

原文链接：https://medium.com/swlh/safely-launch-exception-ready-coroutines-31804de77993

版权

本文探讨了在启动Tomcat时遇到的设备未就绪问题，可能与物联网设备的安全启动和异常处理相关。文章源于对原英文文章的翻译，主要关注在Linux环境下，如何确保Tomcat安全启动并妥善处理启动异常。

摘要由CSDN通过智能技术生成

tomcat启动设备未就绪

Launching suspend functions in Kotlin can be a complicated affair. Managing your CoroutineScope and making sure exceptions are handled properly can be confusing and easy to forget.

在Kotlin中启动suspend功能可能很复杂。管理您的CoroutineScope并确保正确处理了异常会造成混乱，并且容易忘记。

In Android, when using the ViewModel or Lifecycle specific scopes this gets much easier. We let the Android system provide a CoroutineScope and manage killing our coroutines when the lifecycle of those things end.

在Android中，使用ViewModel或Lifecycle特定范围时，这变得容易得多。我们让Android系统提供一个CoroutineScope并在这些生命周期结束时管理杀死我们的协程。

fun getObjectFromNetwork() {
  viewModelScope.launch {
    val response = networkRepository.getObject()
  }
}

However, there are cases when exceptions can be thrown from the CoroutineScope. A real life example I experienced recently was a SocketTimeoutException that was thrown from a Retrofit call I was making using a suspend function. The result is an Android app crash, which is definitely not desired when network calls can result in many different thrown exceptions.

但是，在某些情况下，可以从CoroutineScope抛出异常。我最近遇到的一个现实生活中的例子是SocketTimeoutException ，它是我通过使用suspend函数进行的Retrofit调用引发的。结果是Android应用程序崩溃，当网络调用会导致许多不同的引发异常时，绝对不希望发生此故障。

The Kotlin CoroutineExceptionHandler can help us more easily handle exceptions thrown from our Coroutine scope, but it requires us to register the exception handler when we launch a new coroutine so we properly handle nested exceptions.

Kotlin CoroutineExceptionHandler可以帮助我们更轻松地处理从Coroutine范围引发的异常，但是它要求我们在launch新的协程时注册异常处理程序，以便我们正确处理嵌套的异常。

val coroutineExceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
  // handle thrown exceptions from coroutine scope
  throwable.printStackTrace()
}fun getObjectFromNetwork() {
  viewModelScope.launch(coroutineExceptionHandler) {
    val response = networkRepository.getObject()
  }
}

Now, while the ViewModel is probably a logical place for handling exceptions in network calls, there are a lot of exceptions that are thrown irregularly from your app that aren’t part of the logical flow of a network call. Using Retrofit as an example, most network calls should return a Response with a body() or errorBody() to handle instead of edge-cases where actual exceptions, like a SocketTimeoutException is thrown. It might be worth it to you to abstract this error handling away from your ViewModel to help minimize boiler plate.

现在，虽然ViewModel可能是处理网络调用中异常的逻辑位置，但您的应用程序中有很多异常抛出，这些异常不属于网络调用的逻辑流程。以Retrofit为例，大多数网络调用应返回一个带有body()或errorBody()的Response来处理，而不是抛出抛出诸如SocketTimeoutException类的实际异常的边缘情况。您可能需要从ViewModel抽象出此错误处理，以最大程度地减少样板，这对您来说是值得的。

To try this out, let’s leverage the power of Kotlin extensions to create a safeLaunch method on CoroutineScope that can apply a default CoroutineExceptionHandler.

尝试了这一点，让我们利用Kotlin扩展的力量创造一个safeLaunch的方法CoroutineScope可以应用默认CoroutineExceptionHandler 。

fun CoroutineScope.safeLaunch(launchBody: suspend () -> Unit): Job {
  val coroutineExceptionHandler = CoroutineExceptionHandler { 
  coroutineContext, throwable ->
    // handle thrown exceptions from coroutine scope
    throwable.printStackTrace()
  }
  return this.launch(coroutineExceptionHandler) { 
    launchBody.invoke() 
  }
}

Now, we can call safeLaunch on any CoroutineScope, like our viewModelScope, to launch a coroutine with this default error handling behavior.

现在，我们可以调用safeLaunch任何CoroutineScope ，像我们viewModelScope ，发动协程与此默认的错误处理行为。

fun getObjectFromNetwork() {
  viewModelScope.safeLaunch {
    val response = networkRepository.getObject()
  }
}

There you have it! A nicely-encapsulated method to launch suspend functions knowing that we won’t see random app crashes because of an unhandled Throwable.

你有它！一个很好封装的方法，可以启动suspend函数，因为我们不会因未处理的Throwable导致应用程序崩溃而不会崩溃。

If we wanted safeLaunch to be the core CoroutineScope launch method in our app, we can even improve the extension a bit to allow users the flexibility of passing their own CoroutineExceptionHandler instead of using the default.

如果我们希望safeLaunch成为应用程序中的核心CoroutineScope启动方法，我们甚至可以稍微扩展一下扩展，以允许用户灵活地传递自己的CoroutineExceptionHandler而不是使用默认值。

val coroutineExceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->   
  throwable.printStackTrace()
}fun CoroutineScope.safeLaunch(
  exceptionHandler: CoroutineExceptionHandler = coroutineExceptionHandler,
  launchBody: suspend () -> Unit
): Job {  
  return this.launch(exceptionHandler) { 
    launchBody.invoke() 
  }
}

The same day I wrote this article, Manuel Vivo and Florina Muntenescu from the Android developer relations team released a really good series on coroutines, including the subject of coroutine exceptions. Check it out if you want to learn more about coroutines and how to manage them.

在我撰写本文的同一天，Android开发人员关系团队的Manuel Vivo和Florina Muntenescu发布了有关协程的非常好的系列文章，其中包括协程异常主题。如果您想了解有关协程以及如何管理它们的更多信息，请查看。