Bagaimana untuk mencetak log ralat dalam projek Java

1. Parameter haram yang diperkenalkan oleh sistem atas. Untuk ralat yang diperkenalkan oleh parameter haram, ralat boleh dipintas melalui pengesahan parameter dan pengesahan prasyarat; Terdapat dua jenis ralat yang disebabkan oleh interaksi dengan lapisan bawah:

a. Sistem lapisan bawah berjaya diproses, tetapi ralat komunikasi berlaku, yang akan menyebabkan ketidakkonsistenan data antara subsistem Untuk situasi ini, mekanisme pampasan tamat masa boleh digunakan untuk merekodkan tugasan terlebih dahulu dan membetulkan data kemudian melalui tugasan yang dijadualkan.

Jika anda mempunyai sebarang penyelesaian reka bentuk yang lebih baik, anda juga boleh meninggalkan mesej.

b. Komunikasi berjaya, tetapi ralat berlaku dalam pemprosesan lapisan bawah.

Dalam kes ini, adalah perlu untuk berkomunikasi dengan pembangun peringkat rendah untuk menyelaraskan interaksi antara subsistem

Perlu membuat pemprosesan yang sesuai atau memberi rawatan yang munasabah berdasarkan kod ralat dan perihalan ralat yang dikembalikan oleh maklumat Prompt peringkat bawah.

Dalam mana-mana kes, adalah perlu untuk menganggap bahawa kebolehpercayaan sistem asas adalah purata dan membuat pertimbangan reka bentuk untuk ralat.

3. Terdapat ralat dalam pemprosesan sistem pada tahap ini.

Punca ralat dalam lapisan sistem ini:

Punca 1

: Disebabkan oleh kecuaian. Peninggalan bermakna pengaturcara boleh mengelak ralat tersebut tetapi gagal berbuat demikian. Contohnya, && telah ditaip ke dalam &, == telah ditaip ke dalam =; ralat penghakiman logik majmuk, dsb. Kecuaian sama ada disebabkan oleh kekurangan tumpuan pengaturcara, seperti penat, bekerja lebih masa sepanjang malam, atau menulis program semasa mengadakan mesyuarat atau pengaturcara tergesa-gesa untuk melaksanakan fungsi tanpa mengambil kira keteguhan program, dsb.

Langkah penambahbaikan: Gunakan alat analisis statik kod dan liputan talian ujian unit untuk mengelakkan masalah sedemikian dengan berkesan.

Punca 2

: Disebabkan oleh ralat dan pengendalian pengecualian yang tidak mencukupi. Sebagai contoh, masukkan soalan. Apabila mengira penambahan dua nombor, kita bukan sahaja perlu mempertimbangkan masalah limpahan pengiraan, tetapi juga mempertimbangkan situasi input haram. Bagi yang pertama, ia boleh dielakkan melalui pemahaman, membuat kesilapan, atau pengalaman, manakala bagi yang kedua, ia mesti dihadkan supaya ia berada dalam julat yang boleh dikawal oleh IQ kita, seperti menggunakan ungkapan biasa untuk menapis input yang tidak sah. Ungkapan biasa mesti diuji. Untuk input yang menyalahi undang-undang, berikan maklumat, sebab dan cadangan segera yang terperinci, mudah difahami dan mesra yang mungkin.

Langkah penambahbaikan: Pertimbangkan pelbagai situasi ralat dan pengendalian pengecualian seteliti mungkin. Selepas melaksanakan proses utama, tambah satu langkah: berhati-hati pertimbangkan pelbagai kemungkinan ralat dan pengecualian, dan kembalikan kod ralat yang munasabah dan penerangan ralat. Setiap antara muka atau modul berkesan mengendalikan ralat dan pengecualiannya sendiri, yang boleh mengelakkan pepijat yang disebabkan oleh interaksi adegan yang kompleks dengan berkesan.

Sebagai contoh, kes penggunaan perniagaan dilengkapkan secara interaktif mengikut senario A.B.C. Pelaksanaan sebenar A.B berjaya, tetapi C gagal Pada masa ini, B perlu melancarkan semula kod dan mesej munasabah yang dikembalikan oleh C dan mengembalikan kod dan mesej yang munasabah kepada A. A melancarkan semula berdasarkan pemulangan B dan mengembalikan kod dan mesej yang munasabah. kepada klien dan kod. Ini ialah mekanisme pemulangan terbahagi yang memerlukan setiap senario mempertimbangkan pemulangan semula dalam keadaan tidak normal.

Sebab tiga

: disebabkan oleh gandingan logik yang ketat. Disebabkan gandingan logik perniagaan yang ketat, apabila produk perisian berkembang selangkah demi selangkah, pelbagai hubungan logik adalah rumit dan kompleks, menjadikannya sukar untuk melihat keadaan keseluruhan, menyebabkan kesan pengubahsuaian tempatan merebak ke skop global, menyebabkan masalah yang tidak dapat diramalkan. .

Langkah penambahbaikan: Tulis fungsi pendek dan kaedah pendek, sebaik-baiknya tidak lebih daripada 50 baris untuk setiap fungsi atau kaedah. Tulis fungsi dan kaedah tanpa kewarganegaraan, keadaan global baca sahaja, prasyarat yang sama akan sentiasa mengeluarkan hasil yang sama, dan tidak akan mengubah tingkah lakunya bergantung pada keadaan luaran mentakrifkan struktur yang munasabah, antara muka dan segmen logik untuk membuat sambungan antara antara muka Interaksi sepatutnya; sebagai ortogon dan bergandingan rendah yang mungkin; untuk lapisan perkhidmatan, antara muka yang mudah dan ortogon hendaklah disediakan sebanyak mungkin pembinaan semula berterusan harus dijalankan untuk memastikan aplikasi bermodul dan berganding longgar, dan menjelaskan kebergantungan logik. Untuk situasi di mana sebilangan besar antara muka perniagaan berinteraksi antara satu sama lain, proses logik dan saling kebergantungan setiap antara muka perniagaan mesti diselesaikan dan dioptimumkan secara keseluruhan untuk entiti dengan bilangan keadaan yang besar, yang berkaitan antara muka perniagaan juga perlu disusun atur perhubungan peralihan antara negeri.

Punca 4

: Disebabkan oleh algoritma yang salah.

Langkah penambahbaikan: Mula-mula asingkan algoritma daripada aplikasi. Jika algoritma mempunyai pelbagai pelaksanaan, ia boleh didapati melalui ujian unit semakan silang, seperti operasi pengisihan, jika algoritma mempunyai sifat boleh balik, ia boleh didapati melalui ujian unit semakan boleh balik, seperti penyulitan dan operasi penyahsulitan; .

Punca 5

: Parameter jenis yang sama dihantar masuk dalam susunan yang salah. Contohnya, modifyFlow(int rx, int tx), panggilan sebenar ialah modifyFlow(tx,rx)

Langkah-langkah penambahbaikan: Jadikan jenis sespesifik mungkin. Gunakan nombor titik terapung apabila anda perlu menggunakannya, gunakan rentetan apabila anda perlu menggunakan rentetan, dan gunakan jenis objek tertentu apabila anda perlu menggunakannya dengan parameter yang sama sebanyak mungkin jika tiada satu pun daripada yang di atas boleh; berpuas hati, anda mesti mengesahkannya melalui ujian antara muka , nilai parameter antara muka mestilah berbeza.

Sebab enam

: Pengecualian penunjuk nol. Pengecualian penuding nol biasanya berlaku apabila objek tidak dimulakan dengan betul, atau sama ada objek bukan nol tidak diperiksa sebelum menggunakannya.

Langkah penambahbaikan: Untuk objek konfigurasi, semak sama ada ia berjaya dimulakan untuk objek biasa, sebelum mendapatkan objek entiti untuk digunakan, semak sama ada ia bukan nol.

Punca tujuh : Ralat komunikasi rangkaian. Ralat komunikasi rangkaian biasanya disebabkan oleh kelewatan rangkaian, kesesakan atau tersumbat. Ralat komunikasi rangkaian biasanya merupakan peristiwa berkemungkinan rendah, tetapi peristiwa berkemungkinan rendah berkemungkinan membawa kepada kegagalan berskala besar dan pepijat yang sukar untuk dihasilkan semula.

Langkah penambahbaikan: Buat log INFO pada titik akhir subsistem sebelumnya dan titik masuk subsistem seterusnya masing-masing. Perbezaan masa antara keduanya memberikan petunjuk.

Punca 8: Ralat transaksi dan konkurensi. Gabungan transaksi dan konkurensi dengan mudah boleh menghasilkan ralat yang sangat sukar untuk dikesan.

Langkah penambahbaikan: Untuk operasi serentak dalam program yang melibatkan pembolehubah dikongsi dan pengubahsuaian status penting, log INFO mesti ditambah.

Jika ada cara yang lebih berkesan, sila tinggalkan mesej untuk menunjukkannya.

Punca 9: Ralat konfigurasi.

Langkah penambahbaikan: Apabila memulakan aplikasi atau memulakan konfigurasi yang sepadan, kesan semua item konfigurasi, cetak log INFO yang sepadan dan pastikan semua konfigurasi berjaya dimuatkan.

Sebab 10: Ralat yang disebabkan oleh ketidakbiasaan dengan perniagaan. Dalam sistem sederhana dan besar, sesetengah logik perniagaan dan interaksi perniagaan adalah agak kompleks Keseluruhan logik perniagaan mungkin wujud dalam otak pelajar pembangunan berbilang, dan pemahaman semua orang tidak lengkap. Ini boleh menyebabkan ralat pengekodan perniagaan dengan mudah.

Langkah-langkah penambahbaikan: Reka bentuk kes penggunaan perniagaan yang betul melalui perbincangan dan komunikasi antara berbilang orang, dan tulis serta laksanakan logik perniagaan berdasarkan kes penggunaan perniagaan dan kes penggunaan perniagaan yang terakhir mesti ada; diarkibkan sepenuhnya; Antara muka perniagaan menunjukkan prasyarat, logik pemprosesan, pasca pengesahan dan langkah berjaga-jaga perniagaan apabila berubah, nota perniagaan perlu dikemas kini secara serentak; Anotasi perniagaan ialah dokumen penting untuk antara muka perniagaan dan memainkan peranan caching penting dalam pemahaman perniagaan.

Punca 11: Ralat yang disebabkan oleh isu reka bentuk. Sebagai contoh, kaedah siri segerak akan mempunyai masalah prestasi dan tindak balas perlahan, manakala kaedah tak segerak serentak boleh menyelesaikan masalah prestasi dan tindak balas perlahan, tetapi ia akan membawa bahaya tersembunyi kepada keselamatan dan ketepatan. Pendekatan tak segerak akan membawa kepada perubahan dalam model pengaturcaraan, menambah isu baharu seperti menolak dan menerima mesej tak segerak. Menggunakan cache boleh meningkatkan prestasi, tetapi akan ada masalah dengan kemas kini cache.

Langkah penambahbaikan: Tulis dan semak dokumen reka bentuk dengan teliti. Dokumen reka bentuk mesti menerangkan latar belakang, keperluan, matlamat perniagaan yang perlu dipenuhi, penunjuk prestasi perniagaan yang perlu dicapai, kesan yang mungkin, idea reka bentuk keseluruhan, rancangan terperinci, meramalkan kelebihan, kelemahan dan kemungkinan kesan pelan melalui ujian dan penerimaan; memastikan bahawa perubahan adalah Penyelesaian reka bentuk memenuhi objektif perniagaan dan metrik prestasi perniagaan.

Punca 12: Ralat disebabkan oleh butiran yang tidak diketahui. Seperti limpahan penampan dan serangan suntikan SQL. Dari sudut fungsi, tidak ada masalah, tetapi dari sudut penggunaan berniat jahat, terdapat kelemahan. Untuk contoh lain, jika anda memilih perpustakaan jackson untuk penghuraian rentetan JSON, secara lalai, ralat penghuraian akan berlaku apabila medan baharu ditambahkan pada objek. Anotasi @JsonIgnoreProperties(ignoreUnknown = true) mesti ditambahkan pada objek untuk bertindak balas dengan betul kepada perubahan. Jika anda memilih perpustakaan JSON yang lain, anda mungkin tidak menghadapi masalah ini.

Langkah penambahbaikan: Di satu pihak, adalah perlu untuk mengumpul pengalaman, sebaliknya, mempertimbangkan isu dan pengecualian keselamatan, dan memilih perpustakaan yang matang dan diuji dengan teliti.

Sebab 13: Pepijat yang muncul dari semasa ke semasa. Ia bukan perkara biasa untuk penyelesaian yang kelihatan hebat pada masa lalu menjadi sukar digunakan atau bahkan tidak berguna dalam senario semasa atau akan datang. Sebagai contoh, algoritma penyulitan dan penyahsulitan mungkin telah dianggap sempurna pada masa lalu, tetapi harus digunakan dengan berhati-hati selepas dipecahkan.

Langkah penambahbaikan: Beri perhatian kepada perubahan dan berita pembetulan kerentanan, dan betulkan kod, perpustakaan dan gelagat yang sudah lapuk dengan segera.

Punca Empat Belas: Ralat berkaitan perkakasan. Contohnya, kebocoran memori, ruang storan tidak mencukupi, OutOfMemoryError, dsb.

Langkah penambahbaikan: Tingkatkan pemantauan prestasi penunjuk penting seperti CPU/memori/rangkaian sistem aplikasi.

Ralat biasa yang berlaku dalam sistem:

• Rekod entiti dalam pangkalan data tidak wujud Anda mesti menentukan entiti atau pengecam entiti itu;

• Konfigurasi entiti tidak betul Anda mesti menyatakan konfigurasi yang bermasalah dan apakah konfigurasi yang betul

• Sumber entiti tidak memenuhi syarat. . Anda mesti menyatakan apakah sumber semasa dan apakah keperluannya; dipenuhi dan apakah status semasa;

• Jika semakan pasca operasi entiti tidak berpuas hati, anda mesti menyatakan apakah semakan pasca yang perlu dipenuhi dan status semasa ialah;

• Jika masalah prestasi menyebabkan tamat masa, anda mesti menyatakan apa yang menyebabkan prestasi Soalan, bagaimana untuk mengoptimumkan pada masa hadapan; ralat antara berbilang subsistem membawa kepada status atau data yang tidak konsisten?

Secara amnya, ralat yang sukar dikesan akan muncul di tempat yang agak rendah. Oleh kerana lapisan bawah tidak dapat meramalkan senario perniagaan tertentu, mesej ralat yang diberikan adalah agak umum.

Ini memerlukan penyediaan seberapa banyak petunjuk yang mungkin di peringkat atasan perniagaan. Ralat mesti disebabkan oleh prasyarat yang tidak dipenuhi pada lapisan tertentu timbunan semasa interaksi berbilang sistem atau lapisan. Semasa pengaturcaraan, cuba pastikan semua prasyarat yang diperlukan dipenuhi dalam setiap lapisan timbunan, elakkan menghantar parameter yang salah ke lapisan bawah sebanyak mungkin, dan memintas ralat pada lapisan perniagaan sebanyak mungkin.

Kebanyakan ralat timbul daripada gabungan punca. Tetapi setiap kesilapan pasti ada puncanya. Selepas menyelesaikan ralat, jalankan analisis mendalam tentang bagaimana ralat itu berlaku dan cara mengelakkannya daripada berulang. Anda boleh berjaya dengan kerja keras, tetapi hanya dengan refleksi anda boleh membuat kemajuan! Disyorkan: Pengelogan elegan Java: log4j bab praktikal

Cara menulis log ralat yang memudahkan untuk menyelesaikan masalah

Prinsip asas pengelogan ralat:

1. Selengkap mungkin. Setiap log ralat menerangkan sepenuhnya: ralat yang berlaku dalam senario apa, sebab (atau sebab yang mungkin), cara menyelesaikannya (atau petua penyelesaian); >. Sebagai contoh, jika sumber NC tidak mencukupi, apakah kekurangan sumber khusus yang ia rujuk. Bolehkah ia dinyatakan secara langsung melalui program Untuk ralat umum, seperti VM NOT EXIST, adalah perlu untuk menentukan senario di mana ia berlaku? boleh memudahkan kerja statistik seterusnya.

2. Bersikaplah seterus mungkin . Log ralat yang ideal harus membolehkan orang ramai mengetahui punca dan cara menyelesaikannya pada gerak hati pertama, dan bukannya perlu melalui beberapa langkah untuk mencari punca sebenar.

3. Sepadukan pengalaman sedia ada terus ke dalam sistem . Semua masalah dan pengalaman yang telah diselesaikan harus disepadukan ke dalam sistem dengan cara yang mesra yang mungkin untuk memberi petua yang lebih baik kepada pekerja baharu, dan bukannya berkubur di tempat lain.

4. Susun aturnya hendaklah kemas dan teratur serta formatnya hendaklah disatukan dan diseragamkan. Log padat seperti esei sangat menyayat hati untuk dilihat, agak tidak mesra dan menyusahkan untuk menyelesaikan masalah.

5. Gunakan berbilang kata kunci untuk mengenal pasti permintaan secara unik , menyerlahkan kata kunci: masa, pengecam entiti (seperti vmname), nama operasi.

6. Langkah asas untuk menyelesaikan masalah: Log masuk ke pelayan aplikasi -> Buka fail log -> dalam panduan log ralat untuk menyelesaikan masalah, mengenal pasti dan menyelesaikan masalah.

Antaranya:

Daripada log masuk hinggalah membuka fail log

. Memandangkan terdapat berbilang pelayan aplikasi, adalah menyusahkan untuk log masuk satu demi satu untuk melihatnya. Ia adalah perlu untuk menulis alat dan meletakkannya pada AG untuk melihat semua log pelayan terus pada AG, malah menapis secara langsung log ralat yang diperlukan.

1. Cari lokasi log ralat. Susun atur semasa log adalah padat, menjadikannya sukar untuk mengesan log ralat. Secara amnya, anda boleh mula-mula menggunakan "masa" untuk mencari lokasi berhampiran bahagian hadapan log ralat, dan kemudian gunakan gabungan kata kunci/nama operasi entiti untuk mengunci lokasi log ralat. Walaupun mencari log ralat berdasarkan requestId adalah lebih tradisional, ia memerlukan pencarian requestId terlebih dahulu dan bukan deskriptif. Adalah lebih baik untuk mencari lokasi log ralat secara langsung berdasarkan kata kunci masa/kandungan.

2. 3. Analisis log ralat. Kandungan log ralat hendaklah lebih langsung dan jelas, jelas menunjukkan bahawa ia selaras dengan ciri-ciri masalah semasa yang akan disiasat, dan memberi petunjuk penting.

Biasanya, masalah dengan log ralat program ialah kandungan log hanya boleh difahami berdasarkan konteks kod semasa Ia kelihatan ringkas, tetapi ia sentiasa ditulis tidak lengkap dan dalam format separa bahasa Inggeris sebaik sahaja anda meninggalkan konteks kod, sukar untuk mengetahui apa yang dikatakan. Anda perlu memikirkannya atau melihat kod untuk memahami maksud log. Bukankah ini kes penderitaan diri sendiri? Peluasan: Huraikan secara terperinci pustaka alat pengelogan arus perdana Java

Contohnya:

if ((storageType == StorageType.dfs1 || storageType == StorageType.dfs2)                  && (zone.hasStorageType(StorageType.io3) || zone.hasStorageType(StorageType.io4))) {  // 进入dfs1 和dfs2 在io3 io4 存储。  } else {        log.info("zone storage type not support, zone: " + zone.getZoneId() + ", storageType: "  + storageType.name());        throw new BizException(DeviceErrorCode.ZONE_STORAGE_TYPE_NOT_SUPPORT);  }

zon Apakah jenis storan yang perlu disokong Jangan Biarkan Saya Fikir!

Ralat log harus dapat menerangkan dengan jelas apa yang berlaku walaupun anda meninggalkan konteks kod.

Selain itu, jika anda boleh menerangkan secara langsung sebab dalam log ralat, anda boleh menjimatkan sedikit usaha semasa membuat log pemeriksaan.

Dalam erti kata tertentu, log ralat juga boleh menjadi dokumen yang sangat berguna, merekodkan pelbagai kes penggunaan larian yang menyalahi undang-undang. Kandungan log ralat program semasa mungkin mempunyai masalah berikut:

1 Log ralat tidak menyatakan parameter dan kandungan ralat:

catch(Exception ex){        log.error("control ip insert failed", ex);        return new ResultSet<AddControlIpResponse>(  ControlIpErrorCode.ERROR_CONTROL_IP_INSERT_FAILURE);  }

tidak menyatakan sisipan Ip kawalan gagal Jika anda menambah kata kunci ip kawalan, lebih mudah untuk mencari dan mengunci ralat.

Begitu juga:

log.error("Get some errors when insert subnet and its IPs into database. Add subnet or IP failure.", e);

tidak menyatakan subnet yang mana dan IP mana yang dimilikinya. Perlu diingat bahawa untuk menentukan ini memerlukan kerja tambahan, yang mungkin menjejaskan prestasi sedikit. Di sinilah prestasi dan kebolehpenyahbongkaran perlu ditimbang.

解决方案：使用 String.format("Some msg to ErrorObj: %s", errobj) 方法指明错误参数及内容。

这通常要求对 DO 对象编写可读的 toString 方法。

2.错误场景不明确：

log.error("nc has exist, nc ip" + request.getIp());

在 createNc 中检测到 NC 已经存在报错。但是日志上没有指明错误场景， 让人猜测，为什么会报NC已存在错误。

可以改为

log.error("nc has exist when want to create nc, please check nc parameters. Given nc ip: " + request.getIp());  log.error("[create nc] nc has exist, please check nc parameters. Given nc ip: " + request.getIp());

类似的还有：

log.error("not all vm destroyed, nc id " + request.getNcId());

改成

log.error("[delete nc] some vms [%s] in the nc are not destroyed. nc id: %s", vmNames, request.getNcId());

解决方案：错误消息加上 when 字句， 或者错误消息前加上 【接口名】, 指明错误场景，直接从错误日志就知道明白了。

一般能够知道 executor 的可以加上 【接口名】， service 加上 when 字句。

3.内容不明确, 或不明其义：

if(aliMonitorReporter == null) {          log.error("aliMonitorReporter is null!");  } else {         aliMonitorReporter.attach(new ThreadPoolMonitor(namePrefix, asynTaskThreadPool.getThreadPoolExecutor()));  }

改为：

log.error("aliMonitorReporter is null, probably not initialized properly, please check configuration in file xxx.");

类似的还有：

if (diskWbps == null && diskRbps == null && diskWiops == null    && diskRiops == null) {        log.error("none of attribute is specified for modifying");        throw new BizException(DeviceErrorCode.NO_ATTRIBUTE_FOR_MODIFY);  }

改为

log.error("[modify disk attribute] None of [diskWbps,diskRbps,diskWiops,diskRiops] is specified for disk id:" + diskId);

解决方案：更清晰贴切地描述错误内容。

4.排查问题的引导内容不明确：

log.error("get gw group ip segment failed. zkPath: " + LockResource.getGwGroupIpSegmnetLockPath(request.getGwGroupId()));

zkPath ? 如何去排查这个问题？我该去找谁？到哪里去查找更具体的线索？

解决方案：加上相应的背景知识和引导排查措施。

5.错误内容不够具体细致：

if (!ncResourceService.isNcResourceEnough(ncResourceDO,    vmResourceCondition)) {        log.error("disk space is not enough at vm's nc, nc id:" + vmDO.getNcId());        throw new BizException(ResourceErrorCode.ERROR_RESOURCE_NOT_ENOUGH);  }

究竟是什么资源不够？目前剩余多少？现在需要多少？值得注意的是， 要指明这些要额外做一些事情， 可能会稍微影响性能。这时候需要权衡性能和可调试性。

解决方案：通过改进程序或程序技巧， 尽可能揭示出具体的差异所在， 减少人工比对的操作。

6.半英文句式读起来不够清晰明白，需要思考来拼凑起完整的意思：

log.warn("cache status conflict, device id "+deviceDO.getId()+" db status "+deviceDO.getStatus() +", nc status "+ status);

改为:

log.warn(String.format("[query cache status] device cache status conflicts between regiondb and nc, status of device '%s' in regiondb is %s , but is %s in nc.", deviceDO.getId(), deviceDO.getStatus(), status));

解决方案：改为自然可读的英文句式。

总结起来， 错误日志格式可以为：

log.error("[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do].");  log.error(String.format("[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do].", params));

或

log.error("[Some Error Msg] happens to 错误参数或内容 when [in some condition]. [Probably Because]. [Probably need to do].");  log.error(String.format("[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do].", parameters));

[Probably Reason]. [Probably need to do]. 在某些情况下可以省略；在一些重要接口和场景下最好能说明一下。

每一条错误日志都是独立的，尽可能完整、具体、直接说明何种场景下发生了什么错误，由什么原因导致，要采用什么措施或步骤。

问题：

1.String.format 的性能会影响打日志吗？

一般来说， 错误日志应该是比较少的， 使用 String.format 的频度并不会太高，不会对应用和日志造成影响。

2.开发时间非常紧张时， 有时间去斟酌字句吗？

建立一个标准化的内容格式，将内容往格式套，可以节省斟酌字句的时间。

3.什么时候使用 info, warn , error ?

•  info 用于打印程序应该出现的正常状态信息， 便于追踪定位；

•  warn 表明系统出现轻微的不合理但不影响运行和使用；

•  error 表明出现了系统错误和异常，无法正常完成目标操作。

错误日志是排查问题的重要手段之一。当我们编程实现一项功能时， 通常会考虑可能发生的各种错误及相应原因：

要排查出相应的原因， 就需要一些关键描述来定位原因。

这就会形成三元组：

错误现象 -> 错误关键描述 -> 最终的错误原因。

需要针对每一种错误尽可能提供相应的错误关键描述，从而定位到相应的错误原因。

Atas ialah kandungan terperinci Bagaimana untuk mencetak log ralat dalam projek Java. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!