# Error Handling Error handling is the practice of detecting and responding to errors in software, including recovering from recoverable errors or stopping execution for unrecoverable errors. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Libreboot Build System Audit 3 DevFeed: [Libreboot Build System Audit 3]() Original publisher: [Read original article]() Author: Leah Rowe Published: 2026-09-17T04:32:50.666044Z Content type: article Language: en Sources: [News about Libreboot releases and development]() Topics: [audit](), [maintenance](), [Error Handling](), [Shell]() Tags: [audit](), [audits](), [bios](), [bug](), [build-system](), [canoeboot](), [complexity](), [coreboot](), [efficiency](), [error-handling](), [free-software](), [integrity](), [libre](), [libreboot](), [opensource](), [safety](), [threading](), [uefi]() ### AI overview This article reports on Libreboot Build System Audit 3, focusing on the lbmk build system. It describes improved error handling, bug fixes, efficiency improvements, reduced complexity, stronger vendor-file integrity checks, and broader use of multithreading. The audit reduced the build system from 2,644 to 1,744 shell-script source lines compared with the previous audit, without reducing functionality. ### Source excerpt Article: Libreboot Build System Audit 3 Web link: https://libreboot.org/news/audit3.html ## Is Agentic now tailors its audit by site type DevFeed: [Is Agentic now tailors its audit by site type]() Original publisher: [Read original article]() Author: Rich Haines Published: 2026-09-16T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [audit](), [App](), [API](), [Authentication](), [Error Handling](), [SDKs]() Tags: [api](), [app](), [audit](), [authentication](), [error-handling](), [sdk]() ### AI overview Is Agentic reports now support four site-type views: Docs & content, Business, App, and Commerce. The selected view changes which checks are highlighted, while scores remain comparable and unchanged. ### Source excerpt Is Agentic reports now let you view your checks through one of four site types: Docs & content, Business, App, or Commerce. For example, the Commerce view highlights payment and checkout standards like x402, UCP, and ACP, while the App view highlights API discovery, authentication, error handling, and SDK support. Your score stays the same in every view, and you can change views on an existing report without rescanning. Only the highlighted checks change, so you can focus on what matters for your kind of site while keeping scores comparable across sites. To set the default view, add a single meta tag to your page's : Set the value to match your site type: content for Docs & content business for Business app for App store for Commerce The tag only sets which view readers see first. It doesn't add points or change your score. If no type is declared, Is Agentic infers one and shows which type it chose. Run a check at is-agentic.com or read the documentation. Read more ## Clean Architecture: Use Cases Should NOT Catch Stripe Exceptions DevFeed: [Clean Architecture: Use Cases Should NOT Catch Stripe Exceptions]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-08-27T06:01:02Z Content type: tutorial Language: en Sources: [Optivem Journal]() Topics: [Error Handling](), [stripe]() Tags: [architecture](), [error-handling](), [exceptions](), [stripe]() ### AI overview The article addresses error handling in the application layer and argues that Clean Architecture use cases should not catch Stripe exceptions. ### Source excerpt Error Handling - Application layer ## How to Handle Global Errors in Modern Zoneless Angular DevFeed: [How to Handle Global Errors in Modern Zoneless Angular]() Original publisher: [Read original article]() Author: Jaroslaw Zolnowski Published: 2026-08-04T11:51:30Z Content type: tutorial Language: en Sources: [Daniel Glejzner]() Topics: [Angular](), [Error Handling](), [Web Development]() Tags: [angular](), [async](), [errors](), [exceptions](), [how-to](), [modern](), [user-experience](), [web-development]() ### AI overview This tutorial explains why global error handling changes when Angular applications move from Zone.js to a zoneless model. It introduces provideBrowserGlobalErrorListeners as an Angular v20 tool for handling errors that occur outside Angular's direct control, including unhandled Promise rejections and third-party scripts. ### Source excerpt In the world of web development, unhandled errors are silent threats. They can degrade user experience, cause unpredictable application behavior, and leave developers in the dark. For years, Angular's error handling has benefited from a bit of "magic" ## Building a Testable Network Layer and Three-Tier State Management in Flutter DevFeed: [Building a Testable Network Layer and Three-Tier State Management in Flutter]() Original publisher: [Read original article]() Author: Veli Bacık Published: 2026-07-08T15:56:52Z Content type: tutorial Language: en Sources: [Flutter Community - Medium]() Topics: [Flutter](), [Network](), [API](), [HTTP](), [Refactoring](), [Error Handling](), [JSON](), [ui](), [App]() Tags: [api](), [backend](), [building](), [code](), [dart](), [error-handling](), [flutter](), [how-to](), [http](), [implementation](), [integration](), [json](), [masterclass](), [network](), [refactoring](), [server](), [state-management]() ### AI overview This tutorial explains how to refactor a Flutter application's network and state-management architecture. It introduces a generic, testable network manager and service/model layers, then applies a three-tier state model using Cubit for business state, BlocSelector for targeted rebuilds, and ValueNotifier for widget-local UI state. ### Source excerpt How to wrap HTTP behind a generic, testable network manager with sealed results -- then drive your screens with a three-tier state model: global Cubit, page Cubit, and widget-local ValueNotifier. Flutter Refactoring Masterclass -- Part 3 GitHub - VB10/flight_booking: Flight App for refactoring real project PRs: #11, #12 📺 Video Series: Network & Service Layer https://medium.com/media/2d40d555e4d8968f1d15fb35e2e91553/hrefhttps://medium.com/media/3d8a8a32a77c98177ba10492a892aed6/href 🤖 Want to apply these changes to your project? See the AI prompt at the end. The Problem In Part 2 we split the login page into View, ViewModel, and Mixin -- but the ViewModel still new'd up a Dio() instance and hard-coded http://localhost:8080 inline. Every screen that talked to the backend did the same thing: create a fresh Dio, paste the base URL, decode JSON by hand, and copy-paste the same if (statusCode == 200) ... else ... catch (e) ladder. That pattern rots fast. A URL change means a project-wide search. A new header (auth token, API version) has to be added everywhere. Error handling drifts -- one screen returns 'Server hatası', another swallows the exception. And nothing is testable, because the network call is welded to the widget. As the video puts it: the person writing the code shouldn't be able to say "this only works with internet" -- the network is a dependency, and dependencies must be managed. There's a second rot: state. setState rebuilds the whole widget on every field change. A page with a loading flag, an error string, and a list re-renders all three even when only one changed. And there's no consistent home for "where does the loading state live" -- sometimes a ValueNotifier, sometimes a bool, sometimes buried in _PageState. This article fixes both on the same module. PR #11 builds a generic network + service + model layer. PR #12 layers a three-tier state model on top -- Cubit for business, BlocSelector for surgical rebuilds, ValueNotifier for widget-local UI. What We Change ## Four Habits for Shipping Software with AI Agents DevFeed: [Four Habits for Shipping Software with AI Agents]() Original publisher: [Read original article]() Author: Eric Roby Published: 2026-04-28T12:25:25Z Content type: opinion Language: en Sources: [Eric Roby]() Topics: [Artificial Intelligence](), [Code](), [Large Language Model](), [context](), [Error Handling](), [test]() Tags: [ai](), [ai-agents](), [code](), [context](), [error-handling](), [llm](), [test](), [verification]() ### AI overview A backend engineer shares lessons from using AI agents daily: provide strong context, verify generated work by running code and testing edge cases, and plan for context loss when conversations reset or reach limits. The article argues that effective AI-assisted development requires active engineering judgment rather than blind trust. ### Source excerpt The four habits that separate engineers who ship from engineers who just generate code ## Structured Concurrency DevFeed: [Structured Concurrency]() Original publisher: [Read original article]() Published: 2026-04-13T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Structured concurrency](), [Coroutines](), [kotlin-coroutines](), [Concurrency](), [Error Handling]() Tags: [coroutines](), [error-handling](), [guide](), [kotlin](), [memory-leaks](), [processes](), [structured-concurrency](), [workshop-learning-programming]() ### AI overview A Kotlin-focused guide to structured concurrency explains how coroutine hierarchies establish ownership and completion guarantees. It covers cancellation of child coroutines, avoiding unnecessary work and resource leaks, awaiting completion, and handling errors. ### Source excerpt The only guide to structured concurrency you'll ever need. ## Workflow-as-code: orchestration in pure code DevFeed: [Workflow-as-code: orchestration in pure code]() Original publisher: [Read original article]() Author: Ruben Fiszel Published: 2026-04-03T00:00:00Z Content type: release Language: en Sources: [Windmill Blog]() Topics: [Orchestration](), [Code](), [Python](), [TypeScript](), [Concurrency](), [Error Handling]() Tags: [architecture](), [code](), [concurrency](), [editor](), [error-handling](), [execution](), [launch-week](), [orchestration](), [parallelism](), [python](), [releases](), [typescript](), [version-control](), [workflow](), [workflows]() ### AI overview Windmill introduces workflow-as-code, allowing complex workflows to be defined in TypeScript or Python. The system uses checkpointing and replay, runs tasks as separate jobs, supports parallelism and fault tolerance, and releases workers while workflows wait. ### Source excerpt Introducing workflow-as-code: define complex workflows in TypeScript or Python with checkpointing, parallelism, and fault tolerance built in. ## Revamping Myntra App Analytics persistence with KMP and SQLite DevFeed: [Revamping Myntra App Analytics persistence with KMP and SQLite]() Original publisher: [Read original article]() Author: Kartik Sharma Published: 2026-03-31T13:01:09Z Content type: article Language: en Sources: [Myntra]() Topics: [App](), [SQLite](), [Persistence](), [SDK](), [Databases](), [legacy](), [Error Handling]() Tags: [android](), [app](), [databases](), [error-handling](), [ios](), [kotlin-multiplatform](), [legacy](), [mobile-app-development](), [persistence](), [sdk](), [sqlite]() ### AI overview This engineering post describes Myntra's effort to re-architect the persistence layer of its app analytics SDK. It explains how a legacy Android pipeline using in-memory queues and SharedPreferences created performance and data-reliability bottlenecks as event volume grew, and introduces a SQLite-backed persistence engine intended to improve app stability and data integrity. ### Source excerpt Introduction In the dynamic landscape of e-commerce, data is the bedrock of decision-making, and app stability is the foundation of user experience. At Myntra, where millions of users engage with our platform daily, ensuring the reliability of both is paramount. This necessity drove us to re-architect a critical piece of our infrastructure: the persistence layer of the Myntra app's analytics SDK. This post details our journey of augmenting our legacy analytics SDK with a robust new persistence engine backed by SQLite[1], achieving significant gains in app stability and data integrity. Background: The Limits of the Legacy Pipeline For years, our legacy in-house analytics SDK was the workhorse for collecting user interaction data. However, as our app's event volume grew, the SDK's aging persistence and processing logic created significant bottlenecks that led to degraded app performance and compromised the reliability of analytics data our product teams depended on. On Android: The Legacy Pipeline and its Limits On Android, the legacy analytics pipeline followed a straightforward event processing model: Capture, Persist & Batch: Events generated by used actions were held in an in-memory queue and then serialized into a persistent queue backed by SharedPreferences[2]. Once a batch threshold was met (typically 10 events), the batch was dispatched to the server. Background Flushing: Periodic background jobs flushed unsent events and retried failed batches. Error Handling: Failed batches were pushed to a separate retry queue, with older events silently purged if the queue hit its cap. High level overview of legacy android pipeline At the time of the initial implementation, SharedPreferences was a pragmatic choice to prioritize velocity. The ecosystem for local databases on Android was still maturing, and raw SQLite often required significant boilerplate compared to the simplicity of a key-value store. However, SharedPreferences is architecturally limited for high-throughp ## From error-handling to structured concurrency DevFeed: [From error-handling to structured concurrency]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2026-03-23T15:30:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Concurrency](), [Concurrent Programming](), [Error Handling](), [Exception]() Tags: [concurrency](), [error-handling](), [examples](), [exception](), [exception-handling](), [structured-concurrency]() ### AI overview This article examines how error-handling patterns based on stack unwinding and cleanup should be adapted for concurrent programs with multiple tasks. It introduces the problem of unhandled errors in concurrent execution and compares possible behaviors when one task fails. ### Source excerpt How should we think about error-handling in concurrent programs? In single-threaded programs, we've mostly converged on a standard pattern, with a diverse zoo of implementations and concrete patterns. When an error occurs, it is propagated up the stack until we find a stack frame which is prepared to handle it. As we do so, we unwind the stack frames in-order, giving each frame the opportunity to clean up or destroy resources as appropriate. ## Introducing the Temporal Developer Skill DevFeed: [Introducing the Temporal Developer Skill]() Original publisher: [Read original article]() Author: Ethan Ruhe Published: 2026-03-20T00:00:00Z Content type: release Language: en Sources: [Temporal Blog]() Topics: [AI-assisted coding](), [cursor](), [SDKs](), [Error Handling](), [retry](), [Testing](), [configuration]() Tags: [agent](), [ai-coding-agents](), [cli](), [configuration](), [coverage](), [developer](), [error-handling](), [product-news](), [retry](), [sdk]() ### AI overview Temporal announces the Developer Skill in public preview, providing coding agents with on-demand guidance on Temporal's programming model, SDK best practices, workflows, retries, error handling, testing, and worker configuration. ### Source excerpt Supercharge your AI coding agent with the Temporal Developer Skill. Get expert-level guidance on Workflow determinism, retry policies, and SDK best practices in real-time. ## Error Handling in C, Go, Rust, and Google's Absl DevFeed: [Error Handling in C, Go, Rust, and Google's Absl]() Original publisher: [Read original article]() Author: Nevin Zheng Published: 2026-02-28T00:00:00Z Content type: opinion Language: en Sources: [nevzheng]() Topics: [Error Handling](), [Programming](), [Embedded Systems](), [Microcontroller](), [C](), [Go Language](), [Rust](), [Hardware]() Tags: [c](), [embedded](), [embedded-systems](), [error-handling](), [errors](), [go](), [hardware](), [microcontrollers](), [opinions](), [rust](), [stm32]() ### AI overview An opinionated survey of error handling across C, Go, Rust, and Google's Absl. The article traces error recovery from hardware status registers, interrupts, watchdog timers, and resets to modern language features and libraries, with particular attention to firmware, embedded systems, and microcontrollers. ### Source excerpt Errors, opinions, and the rakes I've stepped on. ## Scalable API Response Handling Across Multi-Layered Architectures with Sandwich DevFeed: [Scalable API Response Handling Across Multi-Layered Architectures with Sandwich]() Original publisher: [Read original article]() Author: Jaewoong Eum Published: 2026-02-08T06:25:14Z Content type: tutorial Language: en Sources: [Stories by Jaewoong Eum on Medium]() Topics: [Android](), [Kotlin](), [API](), [kotlin-coroutines](), [Error Handling](), [Network]() Tags: [android](), [api](), [code](), [communication](), [coroutines](), [error-handling](), [exceptions](), [flow](), [kotlin](), [kotlin-multiplatform](), [mvi](), [mvvm](), [network](), [networking](), [presentation](), [responses](), [retrofit](), [viewmodel]() ### AI overview This tutorial explains how to handle Retrofit API responses, errors, and exceptions across multi-layered Android architectures such as MVVM and MVI. It presents Sandwich as a type-safe, composable approach and covers response handling, composition, merging, global error mapping, and Flow integration. ### Source excerpt Unsplash@picoftasty Modern Android applications commonly adopt multi-layered architectures such as MVVM or MVI, where data flows through distinct layers: a data source, a repository, and a ViewModel (or presentation layer). Each layer has a specific responsibility, and network responses must propagate through all of them before reaching the UI. While this separation produces clean, testable code, it introduces a real challenge: how do you handle API responses, including errors and exceptions, as they cross each layer boundary? Most developers solve this by wrapping API calls in try-catch blocks and returning fallback values. This works for small projects, but as the number of API calls grows, the approach creates ambiguous results, scattered boilerplate, and lost context that downstream layers need. You end up with ViewModels that cannot tell whether an empty list means "no data" or "network failure," repositories that swallow important error details, and data sources that repeat the same error handling pattern dozens of times. In this article, you'll explore the problems that emerge when handling Retrofit API calls across layered architectures, why conventional approaches break down at scale, and how Sandwich provides a type safe, composable solution that simplifies response handling from the network layer all the way to the UI. You'll also walk through the full set of Sandwich APIs, from basic response handling to advanced patterns like sequential composition, response merging, global error mapping, and Flow integration, each with real world use cases that show when and why you would reach for them. Retrofit API calls with coroutines Most Android projects use Retrofit with Kotlin coroutines for network communication. A typical service interface looks like this: https://medium.com/media/ebcba33386d664d1cf69a89234d2e22a/href The service returns a List directly. Retrofit deserializes the JSON response body and gives you the data. This works perfectly when the ## Building an AI REPL with QuickJS DevFeed: [Building an AI REPL with QuickJS]() Original publisher: [Read original article]() Author: James Long Published: 2025-11-18T12:00:00Z Content type: opinion Language: en Sources: [James Long]() Topics: [Artificial Intelligence](), [wasm](), [WebAssembly](), [anthropic](), [Claude Code](), [User experience (UX)](), [C](), [debug](), [Error Handling]() Tags: [ai](), [anthropic](), [bytecode](), [c](), [claude-code](), [debugger](), [error-handling](), [github](), [ux](), [webassembly]() ### AI overview The article describes a three-hour experiment building an AI-integrated REPL with a custom WebAssembly build of QuickJS. The system evaluated JavaScript locally, exposed function bytecode and execution controls, and sent failed evaluations to Anthropic's Sonnet 4.5. The author concludes that the approach was not very useful for simple scripts but sees potential in sharing an executing environment with AI and debugger hooks. ### Source excerpt Yesterday I did a livestream where I built a usable REPL with AI integration. Mostly from scratch, all in 3 hours. It uses a custom WASM build of QuickJS for evaluation. If the evaluation fails, it sends the text to Anthropic to speak to Sonnet 4.5. The idea was to meld a live evaluation environment together with AI. By using QuickJS as an evaluator, we get more than just a sandbox: we are able to inspect bytecode of functions, we could pause execution as needed, etc. I thought we might discover use cases that would be difficult to do by sending JS to eval off to a remote sandbox (or a separate node instance). It's also a UX experiment: you can either write code or talk to AI. In the end, it didn't prove to be super useful. The cases where I want to provide deep introspection at runtime to AI are where I'm already working with a very complex codebase, not writing simple scripts. For the UX, I generally want to write code in a dedicated editor and send it off to be evaluated. I still think there's merit in the idea of sharing an executing environment with AI with the debugger hooks enabled; I'm researching companies working on this. Let me know if you know of any. Still, it was fun to give AI the ability to get the bytecode for a function and describe what the function does at a very low-level. I asked to write a function that sums the numbers in an array, and then asked it to get the bytecode and describe it: Some notable things that happened during this: QuickJS doesn't come with a WASM build by default. I told Claude Code to compile it to WebAssembly, and it got Emscripten all setup and successfully built it to WASM Sonnet 4.5 was able to very easily write a bunch of C code to provide new APIs in QuickJS Changing how error handling works, another example of how nice it was to get AI to work with the C code I intended to eventually dig into QuickJS and change some fundamental features but decided to pause this experiment Adding tools is really fun. Here I added a t ## Promise based Web Worker Messaging DevFeed: [Promise based Web Worker Messaging]() Original publisher: [Read original article]() Author: Stanko Published: 2025-11-03T00:00:00Z Content type: tutorial Language: en Sources: [Stanko Tadić]() Topics: [Promise](), [Messaging](), [Web](), [async/await](), [Code](), [Error Handling]() Tags: [async](), [await](), [code](), [error-handling](), [event](), [implementation](), [messaging](), [thread](), [web](), [worker]() ### AI overview This tutorial presents a Promise-based wrapper for Web Worker messaging. It explains how unique message identifiers map worker responses to stored promises, allowing the main thread to resolve or reject the corresponding promise and use async/await with simpler error handling. The same pattern can also be applied to Service Workers. ### Source excerpt If you've ever used Web Workers (or any other event-based communication), you probably noticed that this kind of code can be hard to read and reason about. You also have to implement some kind of identifier for each message to recognize which worker response corresponds to which request. To simplify that, we can write a small wrapper that lets us use Promises to communicate with Workers. I'll show you an example for Web Workers, but the same pattern can be applied to Service Workers as well. The resulting API looks like this: const workerResponse = await sendToWorker(data); I first used this approach in Pulsar, because I wanted to parse and execute the user's code in a Web Worker, but also wait for the worker to finish before providing data for the next frame. Implementation # The idea is fairly simple - before sending a message to the worker, we create a unique id and a promise. We store the promise in a map using the id as the key. Then we send an event to the worker, including both the data and the id, and return the promise to the caller. When the worker finishes its calculation, it sends back a message that includes the result and the same id. In the main thread, we listen for these messages. When one arrives, we use the id to find the corresponding promise in our map. Finally, based on the worker's result, we resolve or reject that promise. It might sound like a lot, but the code is actually quite straightforward: send-to-worker.jsCopy // Worker initialization const worker = new Worker("./path-to-your-worker.js"); // Map of promises const promises = {}; worker.addEventListener("message", (e) => { // Listen to worker messages and find the correct promise matching the id // Then resolve or reject it depending on the response if (e.data.error) { promises[e.data.id].reject(e.data.error); } else { promises[e.data.id].resolve(e.data.data); } // Remove the resolver reference delete promises[e.data.id]; }); // For identifiers it is safe to use a simple integer // whic ## From prototype to production-ready agentic AI solution: A use case from Grid Dynamics DevFeed: [From prototype to production-ready agentic AI solution: A use case from Grid Dynamics]() Original publisher: [Read original article]() Author: Eugene Steinberg Published: 2025-09-29T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [AI Agent](), [Artificial Intelligence](), [Langgraph](), [Error Handling](), [retry](), [Redis]() Tags: [ai](), [case-study](), [community](), [error-handling](), [langgraph](), [production](), [redis](), [retry](), [state-management]() ### AI overview A Grid Dynamics case study describes building a deep research agent for a Fortune 500 manufacturer. The team used LangGraph initially, then migrated to Temporal after encountering challenges with error handling, retries, state management, caching, scaling, custom workflows, and human-in-the-loop interactions. ### Source excerpt What happens when a promising AI agent prototype hits the high stakes of a prod environment? Grid Dynamics found out the hard way. ## Durable Execution enables resilient agentic workflows in procedural code DevFeed: [Durable Execution enables resilient agentic workflows in procedural code]() Original publisher: [Read original article]() Author: Maxim Fateev Published: 2025-08-20T00:00:00Z Content type: opinion Language: en Sources: [Temporal Blog]() Topics: [agentic workflow](), [Orchestration](), [Persistence](), [distributed-systems](), [Error Handling](), [Code]() Tags: [agentic](), [agentic-workflow](), [agents](), [ai](), [error-handling](), [retries](), [stateful](), [temporal-voices](), [tracing]() ### AI overview This opinion article argues that graph-based frameworks are a poor fit for dynamic AI-agent workflows. It presents Durable Execution as an alternative that lets developers use procedural code while retaining persistence, fault tolerance, incremental execution, error handling, retries, and tracing. ### Source excerpt Graphs break for dynamic AI agents. Durable Execution lets you build resilient, stateful workflows in plain code -- with real error handling, retries, and tracing. ## Error handling in distributed systems: A guide to resilience patterns DevFeed: [Error handling in distributed systems: A guide to resilience patterns]() Original publisher: [Read original article]() Author: Tim Imkin Published: 2025-06-20T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [distributed-systems](), [Resilience](), [Error Handling](), [Remote Procedure Call (RPC)](), [Latency]() Tags: [architecture](), [circuit](), [distributed-systems](), [error-handling](), [how-to](), [idempotency](), [resilience](), [retries]() ### AI overview This guide explains why distributed systems require different error-handling strategies, focusing on partial failures, unreliable networks, latency, partitions, retries with idempotency, and timeouts. It recommends designing for failure through isolation, graceful degradation, and autonomous recovery. ### Source excerpt Master distributed systems resilience with proven patterns like retries, circuit breakers, and Durable Execution to build fault-tolerant apps that never fail. ## Announcing new Temporal training courses for .NET developers DevFeed: [Announcing new Temporal training courses for .NET developers]() Original publisher: [Read original article]() Author: Angela Zhou Published: 2025-02-19T00:00:00Z Content type: release Language: en Sources: [Temporal Blog]() Topics: [.NET](), [SDK](), [Error Handling](), [Tooling]() Tags: [announcements](), [business-logic](), [consistency](), [debug](), [deploy](), [developers](), [durability](), [error-handling](), [free](), [how-to](), [net](), [training]() ### AI overview Temporal announces that its Temporal 101, Temporal 102, and Crafting an Error Handling Strategy courses are now available for .NET developers. The free, self-paced courses cover durable execution, core concepts, architecture, production practices, debugging, deployment, durability, and error-handling strategies. ### Source excerpt Our Temporal 101, 102, and Crafting an Error Handling Strategy are now available in .NET. Take one of our free, self-paced, hand-on courses to learn everything you need to know about Temporal. ## Fail-Fast Error Handling for Resource Loading in iOS Apps DevFeed: [Fail-Fast Error Handling for Resource Loading in iOS Apps]() Original publisher: [Read original article]() Author: Jesse Wilson Published: 2025-01-05T05:38:25Z Content type: opinion Language: en Sources: [Public Object]() Topics: [Error Handling](), [iOS](), [Swift](), [Mobile]() Tags: [crash](), [error-handling](), [ios](), [mobile-apps](), [swift]() ### AI overview The article reflects on whether iOS applications should fail fast or recover gracefully when resource loading fails. It argues that an unrecoverable, unexpected state may justify crashing, while acknowledging the risks of mobile deployments and future API changes. ### Source excerpt The late Joe Armstrong had a great rule for error handling that stuck with me. 'If you can't do what you want to do try to do something simpler' I was thinking about this recently. I was writing code to embed resource files in an iOS application binary. Here' ## Join us for live hands-on Temporal training at Replay 2025 DevFeed: [Join us for live hands-on Temporal training at Replay 2025]() Original publisher: [Read original article]() Author: Angela Zhou Published: 2024-12-02T16:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Development](), [Go](), [Java](), [.NET](), [Error Handling](), [debug](), [test]() Tags: [2025](), [community](), [developer](), [education](), [go](), [java](), [live](), [london](), [net](), [workshops]() ### AI overview Temporal's Developer Education Team is offering two hands-on workshops at Replay 2025 in London: Temporal 102, covering durable execution, testing, debugging, deployment, and event history; and Crafting an Error Handling Strategy, covering failure handling, idempotence, sagas, and heartbeating. The workshops support Go, Java, and .NET developers. ### Source excerpt Replay 2025 is coming to London, England! The Developer Education Team is excited to offer workshops this year in Go, Java, and .NET. ## Scalable JSON Streaming with HTTP and Go - Ep.5 DevFeed: [Scalable JSON Streaming with HTTP and Go - Ep.5]() Original publisher: [Read original article]() Published: 2024-11-25T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Streaming](), [JSON](), [HTTP](), [Error Handling](), [datasets]() Tags: [chunked-transfer-json](), [code](), [data](), [data-transmission](), [decoding](), [decoding-json-streams](), [efficient-json-handling](), [encoding-json](), [encoding-json-in-go](), [error-handling](), [examples](), [go](), [go-json-encoding](), [go-json-memory-management](), [handling-large-json-files](), [how-to](), [http](), [http-chunked-encoding](), [implementation](), [json](), [json-chunked-transfer](), [json-error-logging](), [json-for-engineers](), [json-lines-format](), [json-lines-ndjson](), [json-streaming](), [json-streaming-in-go](), [memory-efficient-data-transmission](), [memory-efficient-json](), [real-time-data-streaming](), [real-time-json-streaming](), [scalable-json-processing](), [streaming](), [streaming-json-over-http](), [streaming-large-json-datasets]() ### AI overview The final episode of the JSON for Engineers series explains how to stream large JSON datasets efficiently using JSON Lines, Go's encoding/json package, and HTTP/1.1 chunked transfer encoding. It covers incremental encoding and decoding, memory usage, response flushing, and logging errors after streaming begins. ### Source excerpt Introduction: Welcome to the final episode of the JSON for Engineers series! In this concluding session, we tackle the challenges of working with large JSON datasets, exploring efficient strategies for streaming data while minimizing memory usage. These techniques enable developers to handle massive payloads without overburdening system resources, ensuring scalable and cost-effective applications. JSON Streaming: Using JSON Lines for memory-efficient data transmission. HTTP Chunked Encoding: Leveraging HTTP/1.1 chunked transfer encoding for streaming large datasets. Practical Error Handling: Logging and managing errors in streaming JSON responses. This episode starts by addressing the inefficiencies of constructing large JSON objects in memory when working with massive datasets, such as database query results. Instead of consuming significant memory to create one monolithic JSON object, the recommended approach involves using JSON Lines (NDJSON), a format where each line represents a separate JSON object. This method reduces memory requirements by transmitting data incrementally. Using Go's encoding/json package, developers can easily encode and stream multiple JSON objects, as it automatically appends newlines between objects. On the receiving end, decoding JSON streams requires careful looping to handle incoming data dynamically while avoiding memory reuse issues, which could lead to errors or stale data. ## Why top developers prioritize failure management DevFeed: [Why top developers prioritize failure management]() Original publisher: [Read original article]() Author: Sergey Bykov Published: 2024-11-05T08:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [Resilience](), [Error Handling](), [distributed-systems](), [Remote Procedure Call (RPC)]() Tags: [developers](), [distributed-systems](), [error-handling](), [resilience](), [retries](), [rpc](), [temporal-concepts]() ### AI overview The article explains why software developers should prioritize failure management and resilience alongside successful execution. It compares RPCs, persistent queues, and workflows as strategies for coordinating distributed systems, highlighting the simplicity and low latency of RPCs alongside their burdens for handling partial failures, recovery, and retries. ### Source excerpt Discover why leading developers focus on failure management. Explore 3 failure-handling strategies and how workflows boost resilience. ## Temporal Announces Four Hands-On Error Handling Training Courses DevFeed: [Temporal Announces Four Hands-On Error Handling Training Courses]() Original publisher: [Read original article]() Author: Mason Egger Published: 2024-10-29T05:00:00Z Content type: release Language: en Sources: [Temporal Blog]() Topics: [Error Handling](), [SDKs](), [reliability](), [Learning](), [retry]() Tags: [error-handling](), [how-to](), [learning](), [reliability](), [retry](), [sdk]() ### AI overview Temporal announces four hands-on training courses that teach developers how to design and implement error-handling strategies for Temporal applications using specific SDKs. ### Source excerpt Errors are bound to happen. When they do, you'll be able to craft a great error handling strategy with the information from our course. [Next page]()