Profiles·Public

pdfjs-dist

semver>=2.0.0postconditions16functions13last verified2026-06-14coverage score100%

Postconditions — what we check

getDocument · getdocument-no-try-catch
error
WhenPDF file is corrupted (InvalidPDFException), encrypted without password handling (PasswordException), URL returns HTTP error (ResponseException), or worker is destroyed mid-load (Error). All propagate when getDocument().promise is awaited without try-catch.
ThrowsInvalidPDFException | PasswordException | ResponseException | FormatError | Error
Required handlingCaller MUST wrap await getDocument(src).promise in try-catch. User-uploaded PDFs are frequently corrupted or password-protected. InvalidPDFException fires on any malformed PDF — a common occurrence in document processing APIs. Check instanceof PasswordException to prompt for password vs generic error handling.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[1][2][3]
getPage · getpage-invalid-page-number
error
Whendoc.getPage(pageNumber) is called without try-catch, and either: (a) pageNumber is out of range (less than 1 or greater than doc.numPages), or (b) pageNumber is not an integer (e.g., a float or NaN), or (c) the PDF worker was destroyed while the page request was in-flight. This is the most common error in PDF processing loops — iterating over pages with incorrect index arithmetic (e.g., starting from 0 instead of 1, or reading doc.numPages but using a 0-based variable).
ThrowsError with message "Invalid page request." (from transport.getPage validation: `!Number.isInteger(pageNumber) || pageNumber <= 0 || pageNumber > pagesMapper.pagesNumber`). Also Error("Transport destroyed") when worker is destroyed after document loaded. These are plain JavaScript Error objects, not pdf.js-specific exception types. Confirmed from node_modules/pdfjs-dist/build/pdf.mjs line 16086: `return Promise.reject(new Error("Invalid page request."))`.
Required handlingCaller MUST wrap doc.getPage() in try-catch. Pages in pdfjs-dist are 1-indexed (first page = 1, last page = doc.numPages). Using 0-based indexing is a common bug. Correct page iteration pattern: try { const doc = await getDocument(src).promise; for (let i = 1; i <= doc.numPages; i++) { const page = await doc.getPage(i); // 1-indexed! const textContent = await page.getTextContent(); // ... process text } } catch (error) { if (error.message === 'Invalid page request.') { console.error('Page number out of range — check 1-based indexing'); } throw error; } finally { await doc.destroy(); } Note: doc.numPages is synchronous (no await needed) once the document is loaded.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]
getTextContent · gettextcontent-no-try-catch
error
Whenpage.getTextContent() is called without try-catch, and the page content stream cannot be parsed (worker-side parsing error). This is more likely with: - Scanned PDFs that have no text layer (returns empty items, but some malformed PDFs cause parsing errors rather than empty results) - PDFs created with obscure or non-standard encodings - Encrypted PDFs where the content stream cannot be decoded - When getDocument() was called with stopAtErrors: true, which causes more parsing errors to propagate rather than being silently recovered The async iteration over the text content stream propagates any worker errors.
ThrowsUnknownErrorException (pdfjs-dist custom class extending BaseException) — thrown when the worker encounters an unrecoverable parsing error during content streaming. AbortException — thrown when doc.destroy() is called while text extraction is in progress (same AbortException class used by getDocument abort). Error — generic errors from the transport layer when the worker is destroyed. All these extend BaseException (except plain Error). Check name property: error.name === 'UnknownErrorException' | 'AbortException'.
Required handlingCaller MUST wrap page.getTextContent() in try-catch. Empty text content (no text layer in a scanned PDF) is returned as {items: [], styles: {}, lang: null} — not an error — so callers should check items.length before assuming text was extracted. try { const textContent = await page.getTextContent(); if (textContent.items.length === 0) { // Scanned image-only PDF — no text layer console.warn('Page has no extractable text (may be a scanned image)'); return ''; } return textContent.items .filter(item => 'str' in item) .map(item => item.str) .join(' '); } catch (error) { if (error.name === 'AbortException') { // Document was destroyed during extraction — expected in cleanup throw new Error('PDF text extraction was cancelled'); } console.error('Text extraction failed:', error.message); throw error; } For batch processing many pages, check for empty results per page, not just errors.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[5][2]
getTextContent · gettextcontent-partial-extraction
warning
Whenpage.getTextContent() completes successfully but the caller does not check for missing or incomplete text data. When getDocument() is called without stopAtErrors: true (the default), malformed page content is silently skipped — some text items may be missing from the result without any error being thrown. This is especially common with: - PDFs with mixed content (some pages have text, some are scanned images) - PDFs with font encoding issues where some characters cannot be decoded - PDFs from certain generators that produce non-standard content streams
ThrowsDoes not throw — silently returns partial TextContent with fewer items than the page actually contains. This is not an exception but a data quality issue. With stopAtErrors: true in getDocument() params, an UnknownErrorException IS thrown instead of returning partial results.
Required handlingFor reliable text extraction, callers should validate the output completeness: 1. Check items.length > 0 (not just that the call succeeded) 2. Consider using stopAtErrors: true if partial extraction is unacceptable: const loadingTask = getDocument({ data: pdfBytes, stopAtErrors: true // reject instead of partial results }); try { const doc = await loadingTask.promise; const page = await doc.getPage(1); const text = await page.getTextContent(); // text.items is guaranteed complete (no silent skips) } catch (error) { // Parsing failure now propagated rather than silently skipped console.error('PDF parsing failed:', error); } 3. For AI/RAG pipelines, always log when items.length === 0 — it indicates a scanned/image PDF that needs OCR processing, not a successful extraction.
costhighin prodsilent failureusers seelost datavisibilitysilent
Sources[6][2]
render · render-no-try-catch
error
Whenawait page.render(params).promise is called without try-catch, and either: (a) renderTask.cancel() is explicitly called (e.g., component unmounts during render) (b) doc.destroy() is called while rendering is in progress (c) The PDF page content cannot be parsed (FormatError, UnknownErrorException) (d) The canvas context is null or invalid (plain Error) RenderTask.promise will reject in all of these cases, causing an unhandled rejection if not caught.
ThrowsRenderingCancelledException (pdfjs-dist custom class, extends BaseException) — thrown when rendering is cancelled (via cancel() or doc.destroy()). name: 'RenderingCancelledException', message: 'Rendering cancelled, page N'. Confirmed from build/pdf.mjs line 16378: `new RenderingCancelledException(\`Rendering cancelled, page \${pageIndex + 1}\`)`. Also: UnknownErrorException (worker-side parsing errors that propagate to render), FormatError (malformed PDF page content stream), plain Error (transport destroyed).
Required handlingCaller MUST await renderTask.promise in a try-catch. In React components and API routes, the most common failure mode is a component unmounting before the render completes — cancel() is called but the rejection still propagates if not caught. const renderTask = page.render({ canvas, viewport }); try { await renderTask.promise; } catch (error) { if (error.name === 'RenderingCancelledException') { // Expected — rendering was cancelled (e.g., component unmounted, page changed) // Do NOT re-throw — this is an intentional cancellation console.log('Rendering was cancelled:', error.message); return; } // Actual rendering error — log and re-throw console.error('PDF rendering failed:', error); throw error; } Note: RenderingCancelledException should NOT be re-thrown in most cases — it is an expected termination signal, not a failure. Only re-throw it if the caller needs to distinguish intentional cancellations from errors.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[7][2]
saveDocument · savedocument-no-try-catch
error
Whendoc.saveDocument() is called without try-catch. The worker thread performs PDF serialization and can fail if the document is large, the worker is destroyed before serialization completes, or an internal serialization error occurs. The returned Promise rejects in these cases.
ThrowsError (generic) — from the transport/worker layer when the worker is destroyed mid-serialization or encounters an internal error. The message may be "Worker was destroyed" or a serialization-specific message. UnknownErrorException — if the worker-side PDF serialization itself fails (e.g., invalid XFA data, malformed annotations). These propagate through messageHandler.sendWithPromise's rejection path. Confirmed from build/pdf.mjs line 16050: uses sendWithPromise which inherits worker error propagation.
Required handlingCaller MUST wrap doc.saveDocument() in try-catch. PDF serialization failures cause silent data loss if uncaught — the user's edits/annotations are not saved. try { const pdfBytes = await doc.saveDocument(); // pdfBytes is Uint8Array — save to storage, send to client, etc. await storage.put('document.pdf', Buffer.from(pdfBytes)); } catch (error) { console.error('Failed to save PDF:', error.message); // Alert user that their changes were not saved throw new Error('PDF save failed — changes not persisted'); } Note: saveDocument() logs a console warning (not an error) when annotationStorage is empty — use getData() instead for unmodified PDFs.
costhighin prodsilent failureusers seelost datavisibilitysilent
Sources[4][2]
destroy · destroy-not-called-finally
error
Whendoc.destroy() is not called in a finally block. If the PDF processing throws an error between getDocument() and a hypothetical destroy() call, the worker thread continues running in the background. In Node.js server environments handling many PDF requests, leaked workers accumulate and cause: - Memory pressure from un-garbage-collected worker threads - Worker pool exhaustion (hit limits on concurrent workers) - Process hanging on exit (active worker threads prevent Node.js from terminating) This is the #1 resource leak in server-side PDF processing with pdfjs-dist.
ThrowsDoes not throw in the common case. However, if destroy() is called while a PDFWorker is in an invalid state (e.g., already destroyed), it may throw Error. Safe to call multiple times — subsequent calls after destruction are no-ops. The issue is the ABSENCE of this call in error paths, not the call itself.
Required handlingCaller MUST use try/finally to ensure destroy() is always called: let doc; try { const loadingTask = getDocument(pdfData); doc = await loadingTask.promise; // Process all pages const results = []; for (let i = 1; i <= doc.numPages; i++) { const page = await doc.getPage(i); const text = await page.getTextContent(); results.push(text.items.map(item => item.str).join(' ')); } return results; } catch (error) { console.error('PDF processing failed:', error); throw error; } finally { await doc?.destroy(); // ALWAYS destroy — even on error } Note: destroy() must be awaited — it is async and the caller should ensure cleanup completes before the function returns. Using void doc?.destroy() without await is a common antipattern that causes race conditions in serverless functions.
costhighin proddegraded serviceusers seedegraded performancevisibilitysilent
Sources[8][2]
cleanup · cleanup-during-rendering
warning
Whendoc.cleanup() is called without try-catch, and one or more pages are currently being rendered (i.e., page.render() has been called and the renderTask.promise has not yet resolved or been cancelled). This is common in SaaS apps that implement PDF thumbnail generation or page viewers where cleanup is triggered by navigation or timeout while a render is in progress. The cleanup call will throw synchronously from the `startCleanup` method after the worker-side cleanup completes but before all pages are cleaned on the main thread.
ThrowsError with message "startCleanup: Page N is currently rendering." where N is the 1-based page number that is still rendering. This is a plain JavaScript Error object (not a pdfjs-dist custom exception type). Confirmed from build/pdf.mjs line 16225: `throw new Error(\`startCleanup: Page \${page.pageNumber} is currently rendering.\`)`. The check `!cleanupSuccessful` is triggered because PDFPageProxy.cleanup() returns `false` when `page._rendering` is truthy.
Required handlingCaller MUST either: (a) wrap doc.cleanup() in try-catch, or (b) ensure all rendering has completed or been cancelled before calling cleanup. Safe pattern — cancel all renders before cleanup: // Cancel any in-progress renders first if (renderTask) { renderTask.cancel(); try { await renderTask.promise; } catch (e) { if (e.name !== 'RenderingCancelledException') throw e; } } // Now cleanup is safe try { await doc.cleanup(); } catch (error) { console.warn('Cleanup failed (rendering may still be active):', error.message); } Alternative: skip cleanup when rendering is uncertain. Note: cleanup() is optional memory optimization — failing silently is acceptable if it's called at an inopportune time. Only cleanup when you KNOW no renders are in progress.
costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]
getData · getdata-no-try-catch
error
Whendoc.getData() is called without try-catch, and the worker thread is destroyed before the data transfer completes. This can happen in SaaS apps when: (a) doc.destroy() is called on one path while getData() is awaited on another (e.g., a request timeout fires while the data is being transferred), or (b) the PDF was loaded from a streaming source and getData() is called before the full document was buffered (returns only the buffered data, or rejects if the transport is not available). The messageHandler.sendWithPromise chain propagates worker errors as rejections.
ThrowsError with message "Worker was destroyed" (or similar) — propagated from messageHandler.sendWithPromise when the worker is terminated before the GetData message response arrives. Also potentially: any Error thrown from the worker thread during data serialization if the PDF is in an unusual state. These are plain JavaScript Error objects, not pdfjs-dist custom exceptions.
Required handlingCaller MUST wrap doc.getData() in try-catch. For PDF download workflows: try { const bytes = await doc.getData(); const blob = new Blob([bytes], { type: 'application/pdf' }); const url = URL.createObjectURL(blob); // Trigger download a.href = url; a.download = 'document.pdf'; a.click(); URL.revokeObjectURL(url); } catch (error) { console.error('Failed to get PDF data:', error.message); // Notify user that download failed showError('PDF download failed. Please try again.'); } finally { await doc.destroy(); } Note: For unmodified PDFs, prefer getData() over saveDocument(). For PDFs where annotations were added, use saveDocument() instead. saveDocument() logs a warning when annotationStorage is empty and suggests getData().
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]
TextLayer.render · textlayer-render-no-try-catch
error
Whenawait textLayer.render() is called without try-catch, and either: (a) textLayer.cancel() is called while rendering is in progress (e.g., user navigates to a different page before the text layer finishes), or (b) doc.cleanup() or doc.destroy() is called while the text layer is reading from the text content stream, causing the stream to error. Both cases reject the render() promise with AbortException. This is common in React-based PDF viewers where a component unmounts or the user pages through the document quickly.
ThrowsAbortException (pdfjs-dist custom class extending BaseException) — thrown when textLayer.cancel() is called or the underlying text content stream is aborted. Message: "TextLayer task cancelled." Name property: 'AbortException'. Confirmed from build/pdf.mjs line 14406: `const abortEx = new AbortException("TextLayer task cancelled.")`. Also: any Error from the text content stream reader errors propagates through #capability.reject — these would be worker errors (UnknownErrorException or plain Error from transport destruction).
Required handlingCaller MUST await textLayer.render() in a try-catch. AbortException should NOT be re-thrown — it is an expected cancellation signal, not a failure. const textLayer = new pdfjs.TextLayer({ textContentSource: page.streamTextContent(), container: textLayerDiv, viewport, }); try { await textLayer.render(); } catch (error) { if (error.name === 'AbortException') { // Expected — text layer was cancelled (e.g., user navigated away) // Do NOT re-throw — this is an intentional cancellation return; } // Actual error — log and propagate console.error('Text layer rendering failed:', error); throw error; } To cancel a text layer render (e.g., on component unmount): textLayer.cancel(); // This rejects the render() promise with AbortException Note: AbortException for TextLayer.render() follows the same pattern as RenderingCancelledException for page.render() — both are intentional cancellation signals that should be caught but not re-thrown.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[9]
extractPages · extractpages-null-return-unchecked
error
Whendoc.extractPages(pageInfos) is called without checking whether the resolved value is null. The worker always resolves (never rejects) — when extraction fails due to: (a) Invalid or out-of-range page indices in pageInfos, (b) The page belongs to a pure XFA document (not supported), (c) Any worker-side serialization error during PDF assembly, (d) A provided external document in pageInfo.document is password-protected and the password callback doesn't provide a valid password, the promise resolves with null rather than a Uint8Array. Code that immediately passes the result to Buffer.from() or downloads it will crash with: "The first argument must be of type string or an instance of Buffer or ArrayBuffer. Received null" (Node.js) or "Failed to construct 'Blob': The provided value cannot be converted to a sequence." (browser).
ThrowsDoes NOT throw. Resolves with null when extraction fails (confirmed from build/pdf.worker.mjs: `catch (reason) { warn(...); return null; }`). Crashes occur DOWNSTREAM when null is passed to Buffer.from(), new Blob([]), URL.createObjectURL(), or written to file. These are plain TypeError or TypeError from the consumer code, not pdfjs-dist custom exceptions.
Required handlingCaller MUST null-check the return value before using the Uint8Array. extractPages() resolves with null on failure — it does not reject. try { const bytes = await doc.extractPages([ { includePages: [[1, 3]] } // extract pages 1-3 (0-based indices) ]); if (!bytes) { // Extraction failed — XFA document, invalid pages, or serialization error console.error('Page extraction failed (XFA documents not supported, or invalid page range)'); throw new Error('PDF page extraction failed'); } // Safe to use bytes as Uint8Array now const blob = new Blob([bytes], { type: 'application/pdf' }); return URL.createObjectURL(blob); } finally { await doc.destroy(); } Note: extractPages() is similar to saveDocument() in that it serializes PDF data, but unlike saveDocument() which throws on worker errors, extractPages() always resolves. Always check for null before processing the result.
costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]
extractPages · extractpages-empty-pageinfos
warning
Whendoc.extractPages(pageInfos) is called with an empty array [] or undefined pageInfos. The worker resolves with null and emits a console warning: "extractPages: nothing to extract." — no exception thrown. SaaS apps that build the pageInfos array dynamically (e.g., from user-selected pages) may pass an empty array when the user deselects all pages. The null result then crashes downstream code identical to the extractpages-null-return-unchecked case.
ThrowsDoes NOT throw. Resolves with null. Confirmed: `if (!pageInfos) { warn("extractPages: nothing to extract."); return null; }` from build/pdf.worker.mjs line 63527.
Required handlingGuard against empty pageInfos BEFORE calling extractPages(): if (!pageInfos || pageInfos.length === 0) { throw new Error('No pages selected for extraction'); } const bytes = await doc.extractPages(pageInfos); if (!bytes) { throw new Error('PDF page extraction failed'); } Alternatively, check the result for null after the call (same null-check pattern as extractpages-null-return-unchecked). Do not skip both guards.
costmediumin prodsilent failureusers seelost datavisibilitysilent
Sources[2]
getOptionalContentConfig · getoptionalcontentconfig-intent-mismatch
error
Whendoc.getOptionalContentConfig({ intent: 'print' }) is called to get a config for print rendering, but page.render({ intent: 'display', optionalContentConfigPromise: ... }) is called with a different intent. The render() method checks that the config's renderingIntent matches the render's intent. When they don't match, it throws inside the rendering callback, causing renderTask.promise to reject with an Error. This is a configuration error that only manifests at render time, not at getOptionalContentConfig() time.
ThrowsError with message: "Must use the same `intent`-argument when calling the `PDFPageProxy.render` and `PDFDocumentProxy.getOptionalContentConfig` methods." Thrown inside render() (not from getOptionalContentConfig() directly). This is a plain JavaScript Error object, not a pdfjs-dist custom exception. Confirmed from build/pdf.mjs line 15594.
Required handlingCaller MUST use the same intent value for both getOptionalContentConfig() and render(). If rendering for display, use 'display' (default) for both: // CORRECT: matching intents const optionalContentConfigPromise = doc.getOptionalContentConfig({ intent: 'display' }); const renderTask = page.render({ canvas, viewport, intent: 'display', // matches getOptionalContentConfig intent optionalContentConfigPromise, // pass the promise directly }); try { await renderTask.promise; } catch (error) { if (error.name === 'RenderingCancelledException') return; console.error('Render failed:', error); throw error; } // WRONG: mismatched intents — will throw at render time const config = doc.getOptionalContentConfig({ intent: 'print' }); page.render({ intent: 'display', optionalContentConfigPromise: config }); // THROWS! Note: getOptionalContentConfig() itself does not throw for normal PDFs that lack optional content groups — it resolves with an empty OptionalContentConfig. Only the render() mismatch check throws. Use intent: 'display' for viewer apps, intent: 'print' for print workflows (PDF → print dialog).
costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]
getPageIndex · getpageindex-invalid-ref-type
error
Whendoc.getPageIndex(ref) is called with a ref argument that is not a valid RefProxy object. A RefProxy must be an object with integer properties num (>= 0) and gen (>= 0). Common mistakes: passing a plain page number (integer), a string, null, undefined, or an annotation object that does not directly expose the internal ref object. PDF annotation data includes a `dest` array whose first element is a RefProxy — callers who pass the annotation object directly instead of annotation.dest[0] will trigger this error.
ThrowsError with message: "Invalid pageIndex request." Thrown synchronously before the worker call (in the transport layer). This is a plain JavaScript Error, not a pdfjs-dist custom exception class. Confirmed from build/pdf.mjs (transport.getPageIndex) lines 16506-16509.
Required handlingCaller MUST pass a valid RefProxy ({ num, gen }) — typically extracted from annotation data or destination arrays, not constructed manually: // CORRECT: extracting ref from destination array const dest = await doc.getDestination(namedDest); if (dest && dest[0] && typeof dest[0] === 'object' && 'num' in dest[0]) { try { const pageIndex = await doc.getPageIndex(dest[0]); navigateToPage(pageIndex + 1); // getPageIndex is 0-based, pages are 1-based } catch (error) { if (error.message.includes('page has been removed')) { console.warn('Link target page was removed from document'); return; } console.error('Failed to resolve page reference:', error); } } // WRONG: passing raw page number or annotation object directly const pageIndex = await doc.getPageIndex(annotation); // THROWS if annotation is not a RefProxy const pageIndex = await doc.getPageIndex(3); // THROWS — integer is not a RefProxy Note: getPageIndex() returns a 0-based index. If using with doc.getPage(), pass pageIndex + 1 since getPage() is 1-based.
costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]
getPageIndex · getpageindex-page-removed
warning
Whendoc.getPageIndex(ref) is called with a valid RefProxy that refers to a page that was removed from the document — for example, after doc.saveDocument() was called on a PDF with page deletions, or when working with a PDF that has been modified externally and reloaded. The pagesMapper resolves the page index from the worker but cannot find the page number (returns 0), triggering this error. This can also occur with annotation targets pointing to deleted pages in documents that have been edited in a PDF viewer before re-loading.
ThrowsError with message: "GetPageIndex: page has been removed." Thrown after the worker responds successfully but pagesMapper lookup returns 0. This is a plain JavaScript Error, not a pdfjs-dist custom exception class. Confirmed from build/pdf.mjs line 16516.
Required handlingCaller MUST catch this error separately from the invalid-ref error to handle gracefully when navigating to annotation targets in edited documents: try { const pageIndex = await doc.getPageIndex(ref); await navigateToPage(pageIndex + 1); } catch (error) { if (error.message === 'Invalid pageIndex request.') { console.error('Invalid reference object passed to getPageIndex'); return; } if (error.message === 'GetPageIndex: page has been removed.') { showUserMessage('The linked page no longer exists in this document.'); return; } throw error; // re-throw unexpected errors }
costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[2]
getDestination · getdestination-invalid-id-type
error
Whendoc.getDestination(id) is called with an id argument that is not a string. Common mistakes: passing undefined (when the destination name is extracted from optional annotation fields), passing the destination array directly instead of the name string, or passing a page number integer when the intent was to use a named destination. PDF annotation objects store the destination as either a string (named destination) or an array (explicit destination) — callers who do not check the type before calling getDestination() will trigger this error when the annotation contains an explicit destination array.
ThrowsReturns Promise.reject(Error("Invalid destination request.")) The promise is immediately rejected without calling the worker. This is a plain JavaScript Error, not a pdfjs-dist custom exception class. Confirmed from build/pdf.mjs (transport.getDestination) lines 16538-16542.
Required handlingCaller MUST verify that the destination id is a string before calling getDestination(). PDF annotation `dest` fields can be either a string (named destination) or an array (explicit destination) — only strings should be passed to getDestination(): // CORRECT: type-guarded navigation const dest = annotation.dest; if (typeof dest === 'string') { // Named destination — look it up try { const destArray = await doc.getDestination(dest); if (destArray) { const pageIndex = await doc.getPageIndex(destArray[0]); navigateToPage(pageIndex + 1); } } catch (error) { console.error('Named destination lookup failed:', error); } } else if (Array.isArray(dest)) { // Explicit destination array — use directly const pageIndex = await doc.getPageIndex(dest[0]); navigateToPage(pageIndex + 1); } // WRONG: passing non-string without type check const destArray = await doc.getDestination(annotation.dest); // THROWS if dest is an array Note: getDestination() resolving with null is NOT an error — it means the named destination doesn't exist in this PDF. Always null-check the resolved value.
costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
Sources[4][2]

Sources

Every postcondition cites at least one of these. Numbered to match the footnotes above.

Need a different package?

Request a profile